相关信息：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 <https://mail.cock.li/> and <https://cock.li/log.txt>.
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] <https://fearsoff.org/research/roundcube>
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.
<https://web.archive.org/web/2005 ... ww.php.net/manual/e
n/function.session-decode.php>
Yep. Someone writing from a french public e-mail host wrote this in 2005
and Roundcube has been running it since 2009. See:
<roundcubemail#617b4f699f>. 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
<php#master>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<php#525f3c4793a6>, 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 <php#3c78ad763ebb>, 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 |
发表于 
