| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 27 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 46:07:27 |
| Calls: | 632 |
| Calls today: | 3 |
| Files: | 1,187 |
| D/L today: |
24 files (29,813K bytes) |
| Messages: | 176,482 |
Some have claimed that Rocksolid Light is insecure. They have claimed
that there are many vulnerabilities in the codebase. They have
claimed that Rocksolid Light should not be used or peered.
Yet I have not seen a single supposed vulnerability demonstrated.
I have not seen any CVE filings.
Can anyone demonstrate and prove any of the claimed exploits?
On 12.07.2025 10:21 Uhr Anonymous wrote:
Some have claimed that Rocksolid Light is insecure. They have claimed
that there are many vulnerabilities in the codebase. They have
claimed that Rocksolid Light should not be used or peered.
Yet I have not seen a single supposed vulnerability demonstrated.
I have not seen any CVE filings.
Can anyone demonstrate and prove any of the claimed exploits?
It least older versions were vulnerable to SQL injections that made
creating files in the spool directory possible. The files.php file also
seems vulnerable to such attacks.
Some have claimed that Rocksolid Light is insecure. They have claimed that there are many vulnerabilities in the codebase. They have claimed that Rocksolid Light should not be used or peered.
Yet I have not seen a single supposed vulnerability demonstrated.
I have not seen any CVE filings.
Can anyone demonstrate and prove any of the claimed exploits?
Where would I find such proofs?
The path traversal vulnerability was used to rescue valuablecommunity data from the rocksolidbbs.com server.
ATTACK TIMELINE
On 12.07.25 17:21, Anonymous wrote:
Some have claimed that Rocksolid Light is insecure. They have claimedthat there are many vulnerabilities in the codebase. They have claimed
that Rocksolid Light should not be used or peered.
Yet I have not seen a single supposed vulnerability demonstrated.
I have not seen any CVE filings.
Can anyone demonstrate and prove any of the claimed exploits?
Where would I find such proofs?
Yes and if anyone is still running [rocksolid / rslight] (PHP):
1. Turn it off!
2. Backup /etc/rslight and /var/spool/rslight folders!
3. Do NOT delete any configs or data!
4. Wait for pugleaf.net open source release!
5. Import to new software and be happy!
If you don't want to turn your rslight off...
Deny access from public and use it locally only.
The path traversal vulnerability was used to rescue valuablecommunity data from the rocksolidbbs.com server.
Works on all other domains too and there is nobody to install a patch.. >Passwords are already leaked... kids found the way in...
That's not the only vulnerability but i won't publish any more details.
We'll see how long his servers and sites keep running.
Domain expiry = end of life for the sites
novabbs.com / novabbs.org / novalink.us will expiry in jan/feb 2026. >rocksolidbbs.com in end of nov 2025 and i2pn2.org end of the year 2025.
Maybe there is credit... but if not ...
... RIP Retro Guy ...
https://github.com/go-while/rocksolid-light/blob/claude-sonnet-4-test2/Rocksolid_Light/CRITICAL_VULNERABILITY.md
https://github.com/go-while/rocksolid-light/tree/claude-sonnet-4-test2
https://github.com/go-while/rocksolid-light
EfU? CRITICAL SECURITY NOTICE
This codebase contains multiple critical security vulnerabilities and is
no longer under active development.
Status: DEPRECATED AND UNSAFE FOR PRODUCTION USE
Path Traversal Vulnerabilities: Complete file system access possible
SQL Injection Attacks: Database compromise via multiple vectors
Input Validation Failures: User input processed without
sanitization throughout
Legacy PHP Anti-Patterns: 20-year-old vulnerable coding practices
Architectural Security Flaws: No security boundaries or privilege
separation
Evidence of Active Exploitation
This codebase was actively compromised for over 1 year (May 2024 - June >2025) with evidence of:
Automated SQL injection campaigns
File system pollution via malicious newsgroup names
Systematic database content extraction
Hundreds of attack artifacts preserved in the filesystem
Why Development Has Stopped
After comprehensive security analysis, this codebase is beyond repair:
50+ distinct attack vectors across all major components
No security architecture to retrofit modern protections
Interconnected vulnerabilities where fixes create new problems
Legacy dependencies that prevent meaningful security improvements
Efoo SECURITY ADVISORY FOR ROCKSOLID LIGHT ADMINISTRATORS
Subject: CRITICAL SECURITY VULNERABILITIES - Immediate Action Required
To: RockSolid Light Administrators From: Security Research Team Date:
June 20, 2025 Severity: CRITICAL
EfU? EXECUTIVE SUMMARY
Multiple critical security vulnerabilities have been discovered in
RockSolid Light installations,
with evidence of active exploitation spanning May 2024 - June 2025.
Any RockSolid Light instance running during this period should be
considered potentially compromised.
rUaN+A IMMEDIATE ACTION REQUIRED
You are running RockSolid Light:
Take your installation offline immediately
Audit your system logs for suspicious activity
Check your spool directory for unusual files (see indicators below)
Consider your system potentially compromised
Do not restart without applying security fixes
Efoi VULNERABILITY DETAILS
Primary Vulnerability: Path Traversal (CVE Pending)
File: /var/www/html/spoolnews/files.php
Impact: Complete file system access
Exploitation: Active attacks documented since May 2024
Vulnerable Code Pattern:
// files.php - Critical path traversal
$getfilename = $spooldir . '/upload/' . $_REQUEST['showfile']; >readfile($getfilename); // NO PATH VALIDATION
Attack Vector:
Attacker extracts site key from HTML form
POST request with malicious showfile parameter
Can read any system file accessible to web server
Enables extraction of SSH credentials, database contents,
configuration files
Secondary Vulnerability: SQL Injection via Newsgroup Names
Impact: Database manipulation and file system pollution
Evidence: Hundreds of malicious database files found
Attack Method: Injection through NNTP protocol and group name
processing
Efo|N+A COMPROMISE INDICATORS
Check your spool directory for files with suspicious names:
# Look for files containing SQL injection patterns
find /var/spool/rslight -name "*CASE WHEN*" -o -name "*SELECT*" -o -name >"*UNION*"
find /var/spool/rslight -name "*ORDER BY*" -o -name "*CONCAT*" -o -name >"*CHAR(*"
Example malicious filenames found:
(CASE WHEN (2018=4830) THEN 'newsgroup' ELSE SELECT...)-data.db3 >comp.lang.python' WHERE 7629=7629 AND 5482=CONCAT...-data.db3 >DOVE-Net.Synchronet_Announcements ORDER BY 3123-- fnTQ-cache.txt
If you find such files, your system has been compromised.
ATTACK TIMELINE
May 2024: First evidence of SQL injection attacks
May 2024 - June 2025: Continuous automated exploitation
March 2025: Retro Guy's system was under active attack during his
final months
June 2025: Vulnerabilities discovered and documented
EfA+ DATA AT RISK
Potentially Compromised Information:
System/Web configuration files and encryption keys
All newsgroup content and user messages
User account databases and authentication data
SSH credentials and server access
Email addresses and user metadata
Any sensitive data accessible to the web server
EfcaN+A IMMEDIATE REMEDIATION STEPS
Emergency Shutdown
# Stop web server and NNTP service immediately
systemctl stop apache2 nginx
Evidence Preservation
# Backup current state for forensic analysis
tar -czf rocksolid-incident-$(date +%Y%m%d).tar.gz /var/spool/rslight/
This vulnerability was discovered during a digital preservation effort >following Retro Guy's passing in March 2025.
The path traversal vulnerability was used to rescue valuable community
data from the rocksolidbbs.com server.
------------------------------------------------------------- >------------------------------------------------------------- >-------------------------------------------------------------
--
.......
Billy G. (go-while)
4. Wait for pugleaf.net open source release!
On 7/22/2025 9:59 AM, Billy G. (go-while) wrote:
4. Wait for pugleaf.net open source release!
When is that gonna be actually? I wanted to put a web-frontend on one
of my little servers and had planned to use rslight, but then the
whole thing happened.
On 26.07.2025 17:06 Uhr Kyonshi wrote:
On 7/22/2025 9:59 AM, Billy G. (go-while) wrote:
4. Wait for pugleaf.net open source release!
When is that gonna be actually? I wanted to put a web-frontend on one
of my little servers and had planned to use rslight, but then the
whole thing happened.
Ask him directly, I don't see a public release yet and the software
itself seems to be not production-ready yet.
On 12.07.2025 10:21 Uhr Anonymous wrote:
Some have claimed that Rocksolid Light is insecure. They have claimed
that there are many vulnerabilities in the codebase. They have
claimed that Rocksolid Light should not be used or peered.
Yet I have not seen a single supposed vulnerability demonstrated.
I have not seen any CVE filings.
Can anyone demonstrate and prove any of the claimed exploits?
It least older versions were vulnerable to SQL injections that made
creating files in the spool directory possible. The files.php file also
seems vulnerable to such attacks.
I started programming in PHP back around the time WordPress was first published. So I know enough to fix a lot of things. Given a list of
the relevant files I can scan and suss out bugs for analysis. I'm not
going to scan the whole source code or try to attack active installs
since others already seem to have done this work. Give me the
relevant file names and I'll have a look.
* Marco Moock wrote:
On 12.07.2025 10:21 Uhr Anonymous wrote:
Some have claimed that Rocksolid Light is insecure. They have claimed
that there are many vulnerabilities in the codebase. They have
claimed that Rocksolid Light should not be used or peered.
Yet I have not seen a single supposed vulnerability demonstrated.
I have not seen any CVE filings.
Can anyone demonstrate and prove any of the claimed exploits?
It least older versions were vulnerable to SQL injections that made creating files in the spool directory possible. The files.php file also seems vulnerable to such attacks.
That would explain how the "haxxor" was able to grab account data for
a technical account for i2pn2.org (presumably the account used for the communication between the rslight frontend and the i2pn2 backend server).
To make things even worse, there is nobody who is able to revokeI am poking around the Rocksolid Light codebase. It would take a sizeable amount of work to fix some of the problems, but it is not insurmountable or gargantuan in scope, although there would be some tedium. It looks like the insecurities can be fixed if some of the attack vectors are gutted:
the compromised account or change its password.
--
-f-a|U-e-u-+ rCo -a-a-|-+-+|U
https://www.eternal-september.org
On Sat, 12 Jul 2025 19:41:55 -0000 (UTC)
Ray Banana <rayban@raybanana.net> wrote:
* Marco Moock wrote:
On 12.07.2025 10:21 Uhr Anonymous wrote:
Some have claimed that Rocksolid Light is insecure. They have claimed
that there are many vulnerabilities in the codebase. They have
claimed that Rocksolid Light should not be used or peered.
Yet I have not seen a single supposed vulnerability demonstrated.
I have not seen any CVE filings.
Can anyone demonstrate and prove any of the claimed exploits?
It least older versions were vulnerable to SQL injections that made creating files in the spool directory possible. The files.php file also seems vulnerable to such attacks.
That would explain how the "haxxor" was able to grab account data for
a technical account for i2pn2.org (presumably the account used for the communication between the rslight frontend and the i2pn2 backend server).
To make things even worse, there is nobody who is able to revoke
the compromised account or change its password.
--
-f-a|U-e-u-+ rCo -a-a-|-+-+|U
https://www.eternal-september.org
I am poking around the Rocksolid Light codebase. It would take a sizeable amount of work to fix some of the problems, but it is not insurmountable or gargantuan in scope, although there would be some tedium. It looks like the insecurities can be fixed if some of the attack vectors are gutted:
* remove the file upload and storage feature except for MIME attachments
* remove code for sqlite spool and force reversion to tradspool
* replace all sqlite functions with plain text parsing functions with santizers
* replace sqlite overview data with plaintext data store
* sanitize / validate web form inputs on the server side before any data is processed
* reject and don't process articles or control messages with badchars or invalid utf-8
* sanitize / validate nntp session commands more thoroughly
* validate and santize BBS mail messages before passing them to further functions or to inboxes.
* replace php pctnl functions with lower-privileged workarounds
* add code to validate and sanitize badchars from being passed to logs, spamassassin, mail server
* sandbox unencrypted nntp port 119 to localhost, forcing bigworld to use TLS in nntp-ssl.php
* going forward commit to zero use of third-party sql / sqlite libraries, and instead create custom functions using PHP native code, relying on tradspool and text files the old Unix way. A properly organized file tree will work as well as a database, with less overhead, just requiring more code, and the main tradeoff is more complex processing versus simple database commands
* going forward commit to a prefix-sorted tradspool tree instead of database message storage
* have tested Rocksolid Light 'as is' for hundreds of newsgroups and it has managed to perform well so far, and since this application is not meant for serving tens of thousands of newsgroups these changes should have negligible impact on performance efficiency
* after fixing the vulnerability vector bugs, begin stress testing by increasing the number of newsgroups and connected users pulling article data and benchmarking until performance upper limits are hit, then identify the bottle necks and optimize from there
What am I missing so far?
I am poking around the Rocksolid Light codebase. It would take asizeable amount of work to fix some of the problems, but it is not insurmountable or gargantuan in scope, although there would be some
* remove the file upload and storage feature except for MIME attachmentssantizers
* remove code for sqlite spool and force reversion to tradspool
* replace all sqlite functions with plain text parsing functions with
* replace sqlite overview data with plaintext data storedata is processed
* sanitize / validate web form inputs on the server side before any
* reject and don't process articles or control messages with badcharsor invalid utf-8
* sanitize / validate nntp session commands more thoroughlyfurther functions or to inboxes.
* validate and santize BBS mail messages before passing them to
* replace php pctnl functions with lower-privileged workaroundslogs, spamassassin, mail server
* add code to validate and sanitize badchars from being passed to
* sandbox unencrypted nntp port 119 to localhost, forcing bigworld touse TLS in nntp-ssl.php
* going forward commit to zero use of third-party sql / sqlitelibraries, and instead create custom functions using PHP native code,
* going forward commit to a prefix-sorted tradspool tree instead ofdatabase message storage
* have tested Rocksolid Light 'as is' for hundreds of newsgroups andit has managed to perform well so far, and since this application is not
* after fixing the vulnerability vector bugs, begin stress testing byincreasing the number of newsgroups and connected users pulling article
What am I missing so far?
Addendum:root user by checking to SUID / RUID at beginning of every script
* configure all scripts and PHP files to prohibit any invocation as
* prohibit running install scripts as root user, except to requestroot for registering init / systemd service for the sync job / cron job
* add a script to automatically check file permissions, reportdiscrepancies, and correct wrong permissions automatically
* bundle with firejail / jailkit / lxd / chroot options includingnetwork shaping in the jail
* bundle with inotify watch helpers to detect, report, and quarantinestray files or changed script files
* bundle with optional Linux MAC options that can be set in a textconfig file
* force install to a single user-owned directory either in /opt or$WEBROOT with .htaccess protections, instead of /etc /var or /run
* slowly work on converting the shell installation scripts to purePHP for a word-press like install from the web front end
* assign IDs and access controls to the individual PHP functions,limiting their inputs and outputs on a per file basis
What am I missing so far?