"Sorry" Ransomware: CVE-2026-41940 Mass Exploitation Underway

We started patching immediately. The issue is that the upcp script isn't pulling the patched version for some legacy CentOS 7 boxes we have. I had to manually force the update:

/scripts/upcp --force

Even then, verify the version hash. If you're on Alma/Rocky, the repositories seem to be updating faster than the older CentOS streams. Be careful with legacy dependencies.

From a detection standpoint, we're seeing the ransomware drop a file named sorry.txt in the root of public_html before encryption starts. You can run a quick scan across your mounted filesystems to check for compromise indicators:

find /home/*/public_html -name "sorry.txt" -o -name "README_SORRY.txt"


If you find this, isolate the host immediately. The encryption logic seems to target specific media extensions first.

For those using ModSecurity, I've drafted a temporary rule to block the specific user-agent string observed in the initial scanner. It's not a fix for the vuln, but it stops the automated drive-by attacks while you patch.

apache SecRule REQUEST_HEADERS:User-Agent "@contains SorryScanner" "id:1001,phase:1,deny,status:403,msg:'Sorry Ransomware Scanner Blocked'"

Remember to tune this so you don't block legitimate traffic if that UA string gets spoofed later.

Excellent advice on the ModSecurity rule. For those who find the sorry.txt artifact, I strongly recommend isolating the host immediately and checking the process tree to identify the parent process of the encryption script. This helps determine if the attacker maintains persistence. You can quickly audit the process hierarchy with this command:

ps -eo pid,ppid,user,cmd --sort=ppid | grep -E "(httpd|sorry)" | head

Also, check your /var/log/cpanel/accesslog for the initial unauthenticated requests hitting the vulnerable endpoint right before the file timestamp.

Solid advice on the artifacts. To add another layer of defense, you should scan for the actual payload binaries often staged in temporary directories before execution. Since the ransomware leaves a specific marker, this YARA rule can help hunt for the dropper on disk:

yara rule Sorry_Dropper { strings: $s1 = "Encrypted by Sorry" wide $s2 = { 45 6C 66 20 } // Hex marker condition: uint16(0) == 0x5A4D and $s1 }

Run yara -r sorry.yara /tmp /var/tmp across your shared hosts to catch binaries missed by basic file scans.

Since the payload is often staged in temporary directories before execution, you can hunt for suspicious binaries in /tmp or /var/tmp. We've observed the malware disguising itself as a system update. You can use this one-liner to flag recently modified executable files to catch the staging phase:

find /tmp /var/tmp -type f -perm -111 -mtime -1 -ls

While patching is priority #1, remember these attacks often leave persistence mechanisms. I recommend auditing cron jobs across all accounts, as threat actors frequently schedule web shell downloads or reinfection scripts. You can quickly dump all user crontabs to a single file for review:

for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done > /root/cron_audit.txt

Since we know the specific behavior, deploying honeytokens in your web roots is a fantastic early warning system. Create a decoy file and monitor its access logs. If the scanner touches it, you know you're being targeted before the payload executes.

touch /home/*/public_html/finance_report_2025.xlsx

Then, simply monitor access-logs for hits on this specific filename. It often triggers an alert before the ransomware even drops sorry.txt.