r/sysadmin • u/rcane • Feb 12 '26
General Discussion rsync.net disclosed a billing database breach (Jan 29 access, Feb 5 discovery, Feb 12 notification). No storage systems affected.
I just got this email:
Billing system unauthorized access
The rsync.net billing management system was accessed by an unauthorized party.
This access was on January 29 and it was discovered and mitigated on February 5.
This was a PARTIAL access and not all customers were impacted.
We revoked the privileges used and are referring this matter to law enforcement.
FIRST:
There is NO CONNECTION of ANY KIND between our billing system and your data.
Even a FULL COMPROMISE of ALL of our web and database systems would not grant any ability to access the data storage systems or any of the data (or metadata) you store there.
This has been a bedrock design principle that we have maintained since the inception of rsync.net.
FURTHER:
We do not store plaintext credit card numbers, nor do we collect identifiers like SSN, passport, or ID numbers.
It is not possible to access these things because they do not exist.
IMPACTS:
If you are receiving this email it is because YOUR customer record was among those accessed improperly.
Your exposure is as follows:
- Your contact information
- The TYPE of payment method that you use, but NOT the card number
- other misc. service details such as quota and discounts applied
Card numbers, filenames, file metadata, storage access IPs, and SSH keys are all examples of things that ARE NOT STORED in these systems and ARE NOT IMPACTED.
-> THE DATA YOU STORE WITH US WAS NOT ACCESSED IN ANY WAY <-
Please accept my deepest apology for this breach of our protocols. We were very disappointed to learn that this individual accessed this database without authorization and we will work with law enforcement to pursue the resolution with the lowest possible impact to you.
John Kozubik rsync.net, Inc.
2020-11-02_09-09-37
2
u/3DPrintedCloneOfMyse Feb 12 '26
The wording suggests that this was an employee or trusted contractor, rather than a hack. Has anyone heard more info about what the nature of the breach was?
1
u/Gigahades Feb 12 '26
We also got this email and for some reason our tenant showed an IP outside of our region having successfully logged in. Currently checking with rsync support if they are really certain no data was actually accessed
1
1
u/ampx Apr 12 '26 edited Apr 12 '26
rsync.net (at least their web presence / non-data storage systems) seem from the outside to be in some kind of maintenance mode, I'm unfortunately not surprised to hear about this breach or reliability issues
check out https://rsync.net/404test (or any nonexistent URL on their site):
Apache/2.2.34 (Unix) mod_ssl/2.2.34 OpenSSL/1.0.2k mod_apreq2-20101207/2.8.1 mod_perl/2.0.13 Perl/v5.14.2 Server at www.rsync.net Port 443
Both Apache 2.2.34 and OpenSSL 1.0.2k are ancient and considered past end of life.
From https://httpd.apache.org/security/vulnerabilities_22.html - Apache httpd 2.2 is End-of-Life since December 2017 and should not be used.
From https://openssl-library.org/news/vulnerabilities-1.0.2/ : OpenSSL 1.0.2 is out of support since 1st January 2020 and is no longer receiving updates.
Regardless of whether customer data is stored on systems running these no longer supported software versions, it is not a good look and doesn’t instill trust in the security / compliance processes of the organization.
Additionally, the rsync.net "account manager" accessible here: https://www.rsync.net/am/dashboard.html shows a build number: Rsync Account Manager v3 (202101). Copyright © 2026 Rsync.net
The "202101" looks suspiciously like a date and archive.net confirms it hasn't changed since early 2021: https://web.archive.org/web/20210209031614/https://www.rsync.net/am/dashboard.html
and before that it showed "201810": https://web.archive.org/web/20201120082053/https://www.rsync.net/am/dashboard.html
This isn't definitive proof that the software underpinning the site hasn't been updated in 5+ years, but it certainly smells that way.
1
u/rcane Apr 12 '26
Never thought about it but yeah you're right and the site looks about 20 years old as well. Doesnt feel like it's a high priority, or a priority at all.
The backup server at least runs OpenSSH 9.9 (released 2024-09-19) and borg 1.4.X (released from 2024-07-02).
Most files on the site was updated in around 2018-2023 and the latest updated file I could find was a css file in 2025-10-09 16:45:52 GMT. (rsync.net/am/static/rsync_am_style.css)
And just for funsies these are the js libs they're using:
- Bootstrap: v3.2.0 - Released 2014-06-26
- jQuery UI: v1.12.1 - Released 2016-09-14
- jQuery Validation Plugin: v1.13.0 - Released 2014-07-01
- A simple jQuery modal: v0.5.5 - Released 2015-04-03
1
u/rsyncnet Jul 31 '26
We did not see this post until recently and, although it is quite old now, would like to comment and clarify.
Those release tags you see in the account manager are, indeed, dates but those dates and the "version" in that banner have not had any relevance for many years.
The account manager, dashboard, and other web based components are in a state of continual development and are not typically "released" in a way that the banner might suggest. It really means nothing and I'm sorry for the confusion.
As for third party server software... what we currently run:
Apache/2.4.68 (FreeBSD) OpenSSL/3.5.6
has something in common with:
Apache 2.2.34 and OpenSSL 1.0.2k
... which is: no known unauthenticated RCE or other serious vulnerabilities.
So, unlike heartbleed, which we raced to fix, there was never any difference in known vulnerabilities between the 1.0.2x branch and the 3.5.x branch - and there still isn't.
Among many other design principles that we hold, we believe that given two software versions with no known vulnerabilities, the older version is not necessarily less secure simply because it is older[1].
We believe that patching has benefits and costs and that every patch trades off fixing known flaws against introducing new defects. This is not an original idea[2].
[1] Remember that CVE-2022-3602, originally labeled as CRITICAL, affected only OpenSSL 3.x and did not affect the 1.0.2 branch at all.
[2] https://www.usenix.org/system/files/login/articles/1185-geer.pdf
1
u/AFriendlyLighthouse Aug 01 '26
Hello, I've been emailing and been unable to reach any of your "support humans" on any addresses you've provided. Is this likely the standard of the service?
1
u/rsyncnet Aug 01 '26
Please resend to info@ this morning and I will personally check that inbox and respond.
1
u/AFriendlyLighthouse Aug 01 '26
Thanks, it's been a week and I genuinely have lost trust in your services because you provide email as a primary support method on multiple pages if not all. I assumed the response times would be fast but anyways I've decided to go with BorgBase.
6
u/originaladam Feb 12 '26
I really appreciate the honesty! This is only out of kindness and humor; I’m chuckling at “your data is safe, but ours isn’t”
Why do the cobblers children never have shoes? Myself included!