The last week of August brought three vulnerability stories worth reading carefully. Each one shows a different failure mode in the patch lifecycle, and each has a lesson for anyone running infrastructure that processes untrusted input.
cPanel: root access without a compromise check
On August 27, cPanel released patches for CVE-2026-65643, a critical flaw in how cPanel and WHM handle domain parking and addon domains. Any account holder with permission to add parked or addon domains can create arbitrary files on the server. From there, exploitation leads to code execution as root. That is the whole server.
The fix covers versions 11.110.0.141, 11.134.0.53, 11.136.0.37, 11.138.0.2, and 11.138.1.7 for WP Squared. Servers set to auto-update get the fix without intervention. Everyone else runs /scripts/upcp --force as root or uses the WHM upgrade panel.
Here is what the advisory does not say. No CVSS score. The CVE Program's official record store still had no entry for CVE-2026-65643 as of August 28, even though it listed two other cPanel flaws from July. No word on whether anyone exploited this. CISA's Known Exploited Vulnerabilities catalog does not include it. And there is no guidance for checking whether an attacker already got in.
That last gap is the frustrating part. In an earlier August advisory covering a Phusion Passenger flaw, cPanel included a command to check Apache error logs for signs of exploitation. WebPros, which develops Plesk alongside cPanel, published a five-item compromise checklist. This advisory gets neither.
I run a few cPanel boxes myself, and the missing forensics guidance bothers me more than the missing CVSS score. The score is a convenience. The compromise check is something you can actually use. If an attacker has been sitting on a server as root for weeks, I want to know before I apply the patch and move on. cPanel wrote these checks a few weeks ago, so they know how.
There is also the unresolved question about older branches. The advisory does not mention DNSOnly, and it leaves open whether versions 11.118 and 11.126 still receive support. cPanel patched those separately in July. If you run one of them, you have to figure out on your own whether you are covered.
TeamCity: the patch existed, nobody applied it
JetBrains confirmed on Friday that attackers breached Cadence, its cloud development service, by exploiting CVE-2026-63077 in TeamCity. This is the one that hurts to read.
The vulnerability lets an unauthenticated attacker execute operating system commands on a vulnerable server. It works through the TeamCity agent polling protocol, which bypasses authentication checks and runs commands with the privileges of the TeamCity server process. Depending on the server configuration, an attacker can expose stored credentials and configuration data, alter the server, or compromise build artifacts and downstream CI/CD pipelines.
JetBrains disclosed the flaw in July. They released fixes in TeamCity 2025.11.7 and 2026.1.3, plus a security patch plugin for customers who could not upgrade immediately. They then reported active exploitation and attempted exploitation against unpatched servers and urged customers to upgrade.
Here is the uncomfortable part: JetBrains, the company that makes the very tool that was exploited, did not patch its own deployment. The disclosure happened in July. The fixes were out. Active exploitation was publicly reported. And the Cadence server was still vulnerable.
The attackers extracted usernames, real names, email addresses, last-login timestamps, and the IP addresses users accessed the service from. They also compromised a full backup of the Cadence server dating from 2024. That backup sits on disk as a persistent target even after the live server gets cleaned.
This is not a case where the patch was hard to find or the upgrade was disruptive. It is a case where a patch was missed on a server that handles CI/CD workloads, which is about the worst possible place to have unauthenticated RCE.
I do not say this to pile on JetBrains. Their disclosure and patch process look fine. But if a company whose core product is build infrastructure can miss this, so can you. Inventory every TeamCity install you have, including the ones running for a department you forgot about.
Rails: a patch that does not fully patch
The Ruby on Rails story is the most technically interesting of the three. CVE-2026-66066, tracked as KindaRails2Shell, carries a CVSS score of 9.5. It is an arbitrary file read that leads to secret exposure, remote code execution, and lateral movement.
The flaw is in Active Storage's image processing with libvips. An unauthenticated attacker can target anything the Rails process can read, including the credential database and storage keys. With those secrets, the attacker can forge sessions, access additional systems, and execute arbitrary code remotely.
Rails disclosed the flaw in late July and rolled out patches, urging anyone using libvips for Active Storage and allowing image uploads from untrusted users to patch immediately. Security researchers reverse-engineered the bug, released PoC code, and Rails published forensic tools for detecting exploitation attempts. VulnCheck reports attackers started exploiting CVE-2026-66066 about a month after patches were released, and in early August it identified around 7,000 exposed Rails instances vulnerable to the flaw.
Here is the part that should worry you. VulnCheck says its tests on a patched 8.1.3.1 server showed that while the fix blocks the libvips file read, it does not neutralize the variation-key Marshal deserialization. The RCE gadget still executes on a patched server given a valid signature.
Patching is necessary but not sufficient here. If an attacker already obtained a valid signature through some other path, the patched server still runs the Marshal deserialization gadget. The fix closes one door and leaves another open. If you run Rails with Active Storage and allow image uploads, patching is step one. Step two is auditing your logs for exploitation attempts using the forensic tools Rails published. Step three is deciding whether you need libvips at all.
Patterns and what to do
Three stories, three different failure modes.
cPanel: the advisory is thin on forensics. Patch it, but do not assume the absence of a compromise check means there was no compromise. Review your server logs, look for unexpected files in domain parking directories, and audit accounts with addon domain permissions.
TeamCity: the patch was available and the server was missed. Inventory your TeamCity installs, including the ones you forgot exist. If you cannot upgrade, install the security patch plugin.
Rails: the patch is incomplete. Apply it, but treat it as a mitigation, not a full fix. Run the forensic tools, review your secrets, and consider the attack surface libvips adds.
The common thread is that none of these advisories should be the end of your investigation. Apply the patches, check your logs, and verify the fix actually holds for your configuration.