Cock.li E-mail Hosting Official Broadcast 16 June 2025 Cockleaks! Roundcube Exposes 1M Login Times, 93k Contacts, and More! -------------------------------------------------------------------- If you ever used webmail, you should change your password just in case. Oh, and Webmail is gone, but you'll have to scroll to yesterday to read about that. You can appreciate the timing, can't you? Well, immediately after posting our announcement that Roundcube is gone from cock.li for good, we received word that two tables from cock.li's Roundcube database is on offer for sale online. The hacker reports they took the `users` and `contacts` tables. We were immediately able to confirm the validity of the leak based on the column count and samples provided. Here's what those tables contained: 1. ~1,023,800 users, everyone that logged into webmail since 2016, and their: -e-mail address -first webmail login timestamp -last webmail login timestamp -failed login timestamp and counter -language -a serialized representation of your preferences, which includes anything you saved into roundcube itself like all of your settings and your signature 2. ~93,000 contact entries from ~10,400 users, including their: -name -email -vcards -comments The ~10,400 users with contacts in the leak will be sent a second e-mail to inform them. Here's what was not leaked to our knowledge: 1. passwords 2. e-mails 3. IP addresses 4. the data of anyone who never used webmail Passwords were stored in the `sessions` table, which is apparently not included in the leak. There was no functioning "Remember me" feature on cock.li's webmail so this would have included the password of anyone actively logged into webmail. About 350 at any time. Still, anyone who used webmail since 2016 should change their password. The leak is being offered for a hefty price. Someone tell Troy we'll send him the usernames ourselves for HIBP if he can prevent Cloudflare from blocking @cock.li etc* from search on that site when using Tor >:( * curl -s https://cock.li/log.txt | tail -20 # get cock.li domains ez OR just turn this off completely why do you need to block that search field anyway WHAT ARE YOU WORRIED THEY WILL FIND This is the part where you're expecting a root cause analysis, incident response, etc. Our guess is CVE-2021-44026 (potential SQL injection) which affected <1.4.12, a version cock.li stopped using long ago. It's possible this data has been held onto for a while. If we match up the columns and get a guess of when this incident occurred you'll get an update on and . There's hardly much more incident response to be done than what's been written here. We removed Roundcube from the service just before learning about this leak. For now the most secure webmail we know of is nothing. One burning question: Could we have prevented this leak by updating Roundcube faster? Probably! We also could have upgraded to the branch with RCE, but don't let that rain on your pitchforks. We could solve this unknown by determining the exact means of exfiltration, but we have already done extensive research on Roundcube and we would rather just take the blame and save the time. Cock.li should not have been running Roundcube in the first place. For the most part, our choice in software has reflected the fact that e-mail has been mostly unchanged for over 40 years. There is no need to get fancy. It's e-mail. The lessons we've learned here will be the foundation for our decisions moving forward. We're deeply sorry for this incident. Over time I'm sure you will find this to be an exception to an otherwise cautious security philosophy and structure. Cock.li Administration Team official-contact // cock.li ~!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!~ Cock.li E-mail Hosting Official Broadcast 15 June 2025 Roundcube RCE Enabled By Code It Still Uses From 2005 PHP.net Post ------------------------------------------------------------------ Also: Updates on the Future of Webmail A recent vulnerability in Roundcube, the webmail software cock.li uses, has been exploited by hackers to obtain remote code execution on thousaunds of web servers running this e-mail software. This exploit was sold on hacking forums and has now been made public. After quarantining the relevant server and investigating the damage, we discovered that... the vulnerability does not appear to be exploitable on 1.4.15 and 1.4.x, despite public reports to the contrary. The data we quarantined showed no signs of intrusion or successful exploitation. So, our lazy decision to run this end-of-life branch saved us this time, but it could have easily gone different. We will learn carefully from this near miss. Not to excuse the delay in updating you, we have been investigating this vulnerability, the security of Roundcube, and our options for the future of webmail on cock.li. All your questions will now be answered. TECHNICAL FINDINGS ------------------ The original research[0] of CVE-2025-49113 points out this particular line in rcube_session.php: function unserialize() (line 539): [0] 513 /** 514 * Unserialize session data 515 * https://www.php.net/manual/en/function.session-decode.php#56106 516 * 517 * @param string $str Serialized data string 518 * 519 * @return array|false Unserialized data 520 */ 521 public static function unserialize($str) 522 { 523 $str = (string) $str; 524 $endptr = strlen($str); 525 $p = 0; 526 527 $serialized = ''; 528 $items = 0; 529 $level = 0; 530 531 while ($p < $endptr) { 532 $q = $p; 533 while ($str[$q] != '|') { 534 if (++$q >= $endptr) { 535 break 2; 536 } 537 } 538 539* if ($str[$p] == '!') { 540 $p++; 541 $has_value = false; 542 } else { 543 $has_value = true; 544 } 545 546 $name = substr($str, $p, $q - $p); 547 $q++; The author makes a couple observations: 1. There is nothing about this function or an "!" in the link provided. 2. What the hell is "!" doing there anyway? Without knowing its origin, the author correctly points out the lack of bounds checks on the condition which (when provided with an unsanitized, user-provided value..) allows for the object insertion and RCE reported. To operate the link provided, and to truly understand the issue, you will need to go back. WAY back. Ahem. Yep. Someone writing from a french public e-mail host wrote this in 2005 and Roundcube has been running it since 2009. See: . The author is "svncommit" and apparently the subversion repository went private in 2006. Is that all? Nope. Apparently the use case for this function is to fix an issue present in 2005 PHP's native session_decode() handling of "reserved chars", as well as to allow deserialization of data outside of sessions. It's unknown if that issue is still present 20 years later. Instead of getting lost in the sauce here, let's answer the other question: What is "!" doing there? To do that, we'll turn to PHP's source code. in ext/session/session.c, there's no mention of it anymore. PHP now uses binary decoding only and has PS_BIN_UNDEF: 981 #define PS_BIN_UNDEF (1<<(PS_BIN_NR_OF_BITS-1)) But when you roll back the clock to around the time this function was added, you see it there: 761 #define PS_UNDEF_MARKER '!' So "!" is actually PS_UNDEF_MARKER and denotes a null value. This same name was used in the 2005 php.net post, but it was replaced with a static value in Roundcube. Otherwise, PS_SERIALIZED_DECODE_FUNC follows nearly identically with the PHP code above. And so, does this commit of PHP have the same vulnerability? Yes, it does. Reported as CVE-2010-3065 and MOPS-2010-060: PHP Serializer Session Data Injection Vulnerability, this same issue was fixed on 2010-04-26 at , and released in PHP 5.2.14 and 5.3.3. Turning back to Roundcube, how close is the current unserialize() function to the 2005 reproduction? The loop style, capitalization, indentation, and spacing has all been changed. "!" and "|" are written inline. Syncing all of that up is a painstaking process but yields the following diff between roundcube's unserialize($str) and bmorel's 2005 session_real_decode($str): 32c32 < switch (strtolower($str[$q])) { --- > switch ($str[$q]) { 47c47 < $serialized .= 'R:' . (intval($id) + 1) . ';'; --- > $serialized .= 'R:' . ($id + 1) . ';'; 82c82 < return unserialize('a:' . $items . ':{' . $serialized . '}'); --- > return @unserialize( 'a:' . $items . ':{' . $serialized . '}' ); So, roundcube's unserialize function is functionally the exact same as this 2005 reproduction with the following improvements: 1. Type identifiers are cast to lowerstring 2. Reference values are cast to integers 3. Error reporting is uninhibited 4. "!" and "|" are written inline instead of assigned to variables like PS_UNDEF_MARKER Well, with that out of the way we can now finally tell a more complete story of the issue. Drumroll please................ Roundcube's CVE-2025-49113 happened because 1.5.x and 1.6.x got a shiny new unsanitized user input "_from", which got passed to rcube_session.php:unserialize(), a 2005 rehash of PHP's own session_decode() added to Roundcube by "svncommit" in 2009. The version of PHP the rehashed function was based on is vulnerable to CVE-2010-3065, and the rehashed function in Roundcube was never updated. PHP now uses binary serialization only, and Roundcube added sanitization to prevent the vulnerable code from being exploited. WHERE IS WEBMAIL? ----------------- Cock.li will no longer be offering Roundcube webmail. Regardless of whether our version was vulnerable to this, we've learned enough about Roundcube to pull it from the service for good. Another webmail is definitely on the table, but it is not an immediate priority for us. Maybe we'll get the one with the squirrel on it. Until then, it's time for you to learn a mail client. Good luck, Cock.li Administration Team official-contact // cock.li