Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Ruby on Rails

  • Four of today’s nine stories are about the gap between a fix and the record of it

    Four of today’s nine stories are about the gap between a fix and the record of it

    The item to act on tonight is Ruby on Rails, and it is not the biggest-sounding thing that happened today. Rails’ patch for CVE-2026-66066 stops the file read that leaks secret_key_base. It does not stop the Marshal deserialization gadget that read exposed, which still executes on a fully patched server for anyone holding a valid key. An organization that upgraded in early August and did nothing else is closed to the theft and still open to code execution by whoever completed the theft first. Patch status and compromise status have come apart here, and the step that reconciles them — rotating secret_key_base and every other secret readable from the application process — is the one no scanner reports as missing. VulnCheck says exploitation began the week of August 24. That claim is thin, and it is not what should decide this: a working exploit against more than 7,100 exposed instances has been public since August 7.

    Bigger headlines were available today, and both of them shrank on inspection. The Justice Department rewrote its China hacking announcement so that NASA, the Federal Reserve, and the Senate are now “among the targets” of QTFY rather than its victims — a withdrawal, not an escalation. And a 9.8 critical CVE for the open-source project hulumi turns out to describe an over-permissive IAM policy in the project’s own CI sandbox account, a resource nobody who installs hulumi has.

    The day did have a thread, and it is a narrow one: in four of the nine stories, the fix and the record of the fix do not match. Rails is one. Nodemailer’s new 9.8 names 8.0.3 as the fixed version, and the 8.0.3 tarball on npm still carries the vulnerable line. Eight MCPHub CVEs published within a single second this afternoon carry fixes shipped between April 22 and August 23 — the critical remote code execution among them was fixed in May and disclosed today. And Eclipse Theia’s agent-mode workspace escape, an 8.8 that let the AI agent write and delete files outside the workspace on a model-supplied path, was closed in a release whose notes described the change only as a breaking API change. The engineering is not the failure in any of the four. The patch exists in all of them. What is unreliable is the thing a vulnerability management program actually reads.

    Second for most shops is Microsoft’s confirmation that Windows is falsely reporting Defender as turned off across effectively every supported client and server version, with no originating update to roll back, no named build to compare against, and alerts that persist even when notification settings are off. Expect it at the service desk at boot tomorrow, and brief staff with Get-MpComputerStatus rather than “ignore it” — the alert being trained out is the tamper signal.

    Then the rest. Seven ToolJet CVEs describe the same cross-tenant authorization gap in tooljet-db, and the worst of them carries a 9.9 and a 2.4 from the same scorer in the same record, against the vendor’s own 5.9. Nutex Health refiled its August 24 breach disclosure under Item 1.05 seven days later without adding the materiality determination that item exists for — a change of flag that automated screening will read and the filing’s own text contradicts.

    Still open: Microsoft has named neither the Defender build that causes the false alert nor a fix date. VulnCheck has published no correction on the ToolJet scoring conflict or the Nodemailer fixed-version range. The Justice Department has not said which, if any, of the seven named bodies QTFY actually compromised, and the pre-edit wording survives only in contemporaneous reporting. Nutex has not said whether it made a materiality determination, and the affected-individual count will come from state and federal breach portals, not EDGAR. And the Rails exploitation claim still rests on one social media post that VulnCheck’s own weekly report for that week does not list.

  • Rails’ KindaRails2Shell patch stops the file read, not the code execution: a stolen signing key still runs on a fixed server

    Rails’ KindaRails2Shell patch stops the file read, not the code execution: a stolen signing key still runs on a fixed server

    Rails fixed the file read on July 29. VulnCheck says the deserialization gadget it exposed still runs on a patched server for anyone holding the stolen key.

    Ruby on Rails patched CVE-2026-66066 on July 29, 2026. On Monday, August 31, 2026, SecurityWeek reported that VulnCheck had observed threat actors exploiting it, saying attacks began the previous week — roughly the seven days from August 24 — about a month after the fix shipped. That is the new development. The vulnerability itself, the patch, and the exposure count are all from late July and early August.

    The part that has not been widely reported is what the patch does not do. VulnCheck’s own analysis, published August 7, 2026, states 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.” An organization that upgraded Rails in early August and did nothing else is closed to the file read that steals the signing key, and still open to code execution by anyone who already has it.

    What happened

    The flaw, nicknamed KindaRails2Shell by its discoverer Ethiack, is in Active Storage’s handling of image variants. Rails’ advisory GHSA-xr9x-r78c-5hrm describes it in one sentence: “In its default configuration, a Rails application that displays image variants may allow an unauthenticated attacker to read arbitrary files from the server, including the process environment.”

    The mechanism is a file-format trick. Rails’ own writeup explains that “HDF5’s External File List lets a dataset’s bytes live in another file named by path and offset, so rendering the ‘image’ reads an attacker-chosen file off the server and returns its contents as pixels.” An uploaded file that presents as an image to one parser and as an HDF5 dataset to another turns Rails’ thumbnailer into a file reader. What comes back is rendered as an image, and the attacker decodes the pixels.

    Affected versions, from the Rails advisory: activestorage before 7.2.3.2, 8.0 through 8.0.5.0, and 8.1 through 8.1.3.0. Fixed in 7.2.3.2, 8.0.5.1, and 8.1.3.1. GitHub scored it CVSS v4.0 9.5 with the vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H — network reachable, no privileges, no user interaction, total confidentiality, integrity, and availability impact, and the same again on downstream systems.

    The exploitation history has been contested from the start, and it is worth laying out in dates rather than in adjectives. Rapid7 published its analysis on July 30, 2026 and wrote: “As of July 30, 2026, Rapid7 is not aware of exploitation in the wild.” It added that “public code claiming to exploit CVE-2026-66066 exists, but it is unclear how closely it corresponds to the full attack chain reported privately to Rails.” On August 4, 2026, CISA’s automated SSVC assessment on the CVE record set exploitation to proof-of-concept, automatable to yes, and technical impact to total. On August 7, 2026, VulnCheck published its own exploit, a Docker target, packet captures, Suricata, Snort, YARA, and Sigma rules, and a count of “7,100+ exposed vulnerable instances of Ruby on Rails” — and said, in the same document, “No exploitation has been reported yet, but given the deployment footprint and public information, we would expect it to follow shortly.”

    That August 7 document is the page SecurityWeek links to for the CVE in its August 31 story, and it still reads that way. The exploitation claim in that story is attributed to VulnCheck separately, by way of a LinkedIn post. VulnCheck’s published weekly initial-access report covering August 22 to August 28 — the week in which the attacks are said to have started — summarizes new exploits for DARKLANTERN, SPEAKINGSTONE, Windows Defender, Zimbra Collaboration, GeoServer, Flowise, and Langflow. It does not list Ruby on Rails or CVE-2026-66066.

    Severity Daily could not reach the LinkedIn post. So the state of the evidence, stated plainly: exploitation is reported by a credible vendor through a social media post, relayed by a credible publication, and is not reflected in that vendor’s own dated exploitation record, in the CVE record, or in CISA’s Known Exploited Vulnerabilities catalog, which does not list CVE-2026-66066.

    The CVE record is its own problem. NVD published CVE-2026-66066 on July 30, 2026 and last modified it on August 5, 2026. Its vulnStatus is still “Received” — NVD has not analyzed it. There is no NVD-assigned CVSS score. The only base score on the record is the 9.5 supplied by GitHub as a secondary source, plus CISA’s SSVC block. Thirty-two days after a critical, unauthenticated, network-reachable flaw in one of the most widely deployed web frameworks in production, the authoritative U.S. vulnerability record has not been touched by an analyst.

    Why it matters

    The gadget finding is the one that changes what teams have to do, and it is buried in a vendor research page rather than carried in the advisory. Rails’ fix stops the file read. It does not stop the second half of the chain, because the second half was never the bug — it is the framework working as designed. Active Storage signs variation keys and deserializes them; given a valid signature, it will keep doing that on a fully patched 8.1.3.1 server.

    The practical consequence is that patch status and compromise status are decoupled here. If an application was exposed between late July and whenever it was upgraded, and an attacker read secret_key_base out of the process environment during that window, the upgrade does not evict them. They hold a key that signs anything the application will accept, on a server that reports itself as fixed. This is not a hypothetical corner of the vulnerability; it is the reason Rapid7’s guidance says to rotate “secret_key_base and other secrets accessible to the application process” as a distinct step from upgrading.

    Credential rotation is the step organizations skip. It is disruptive, it touches sessions and signed cookies and anything else keyed off the same secret, and it does not show up as a missing patch on any scanner. A vulnerability management program that measures itself on version compliance will mark this closed and be wrong.

    The exploitation reporting matters less than it appears to, and it is worth being clear about why. Whether attacks began on August 24 or have not begun at all does not change the action list. VulnCheck published a working exploit on August 7, along with detection rules, which means the exploit has been public and packaged for three weeks against a target set the same vendor measured at more than 7,100 internet-facing instances. The right posture does not wait for confirmation. But the reporting does matter for anyone whose escalation process requires evidence of active exploitation before they can take an outage window, and those teams deserve to know that the evidence is currently one social media post that the vendor’s own exploitation record does not corroborate.

    The empty NVD record compounds it. A team triaging this from a feed keyed to NVD sees a critical CVE with no analyst-assigned score, no CPE configuration data to match against an asset inventory, and no KEV entry. Everything useful about this vulnerability — the affected version ranges, the workarounds, the gadget that survives the patch, the exposure count — lives in a GitHub advisory and two vendor blogs. That is the recurring shape of the problem this publication keeps finding: the record that everyone’s tooling reads is the record that says the least.

    What to do

    Upgrade to Rails 7.2.3.2, 8.0.5.1, or 8.1.3.1, and confirm libvips is 8.13 or later. If you cannot upgrade immediately, set the VIPS_BLOCK_UNTRUSTED environment variable with libvips 8.13 or later, or call Vips.block_untrusted(true) from an initializer with ruby-vips 2.2.1 or later. If your application pulls in ruby-vips only for image analysis rather than Active Storage variant processing, the advisory’s third option is to remove the dependency.

    Then rotate secret_key_base and every other secret readable from the application process environment. Treat this as required, not optional, for any application that served image variants on a vulnerable version with untrusted uploads. Patching without rotating leaves the signature-gated code execution path intact.

    Check whether it was ever exposed before you decide. The file read returns arbitrary paths as image bytes, so look for variant requests that produced unusually sized or malformed outputs, uploads whose declared type does not match their container, and any HDF5 signature in stored blobs. VulnCheck’s August 7 release includes Suricata, Snort, YARA, and Sigma rules and packet captures, which is the fastest way to get retroactive detection in place.

    Sourcing note

    Checked: the Rails GitHub Security Advisory GHSA-xr9x-r78c-5hrm for affected and fixed versions, the CVSS v4.0 vector, and the workarounds; the NVD API record for CVE-2026-66066 for its published and last-modified timestamps, its “Received” status, the absence of an NVD-assigned score, the CISA SSVC block dated August 4, 2026, and the absence of any cisaExploitAdd or cisaActionDue field; VulnCheck’s dated initial-access documentation for August 1 to 7, 2026 and for August 22 to 28, 2026; Rapid7’s July 30, 2026 analysis; SecurityWeek’s August 31, 2026 report.

    Not reached: the VulnCheck LinkedIn post that is the stated source for the exploitation claim. cisa.gov returns 403 to automated fetching, so the KEV catalog was checked through the NVD record’s CISA fields rather than the catalog page itself; NVD lags the catalog by hours, so a very recent addition would not appear there.

    Unresolved: whether exploitation of CVE-2026-66066 is occurring. One vendor says it began in the week of August 24; that vendor’s own published exploitation report for that week does not list it, and no CVE or catalog record reflects it. Also unresolved: why NVD has not analyzed a CVSS 9.5 record thirty-two days after publication.