Rietta published a technical incident analysis after an emergency update to a government client’s Rails application. In the analysis, Rietta described vulnerability exploitation attempts that followed the update.

The analysis covers CVE-2026-66066, a critical remote code execution vulnerability in ActiveStorage for Ruby on Rails 8 and later versions. By the evening of July 29, the vulnerability’s CVSS score had reached 9.5 out of 10.

When updating affected applications, Rietta ran full automated tests. The company deployed the fix to production only after the tests passed.

The first attack attempt against the government client’s application took place on July 30 after the fix was applied. A continuous wave of probes using a spoofed PNG file began on August 3.

Claim check:

  • Rietta published a technical incident analysis describing an emergency update to a government client’s Rails application and the vulnerability exploitation attempts that followed. (confirmed by the publication itself: evidence; «Rietta patched a government client running a Ruby on Rails website within hours of a 9.5 CVSS ActiveStorage CVE. Exploit attempts began before business hours resumed.»)
  • The analysis concerns CVE-2026-66066 (KindaRails2Shell), a critical remote code execution vulnerability in ActiveStorage for Ruby on Rails 8 and later versions. (confirmed by the publication itself: evidence; «After hours on Wednesday, July 29, 2026, Rietta executed our emergency hotfix procedure across our entire client base for sites impacted by a severe remote code execution vulnerability in ActiveStorage, a component of Ruby on Rails 8 and newer.»)
  • According to Rietta, by the evening of July 29 the vulnerability’s CVSS score had reached 9.5 out of 10, after which the company announced an emergency fix. (confirmed by the publication itself: evidence; «By evening, though, our team saw it had climbed to an extremely severe 9.5/10 CVSS score.»)
  • When updating affected Rails applications, Rietta ran full automated tests and deployed the fix to production only after they passed. (confirmed by the publication itself: evidence; «Only once the full test suites passed cleanly, confirming nothing else had broken, we deployed to production.»)
  • Rietta says the first attack attempt against a government client’s application occurred on July 30 at 07:10:25 EST, eight hours and one minute after the patch was applied. (confirmed by the publication itself: evidence; «The first attack against our client predates all of that. It hit at 7:10:25 AM EST on July 30th, eight hours and one minute after we applied the patch,»)
  • According to Rietta, a continuous wave of probing attempts began on August 3 using a spoofed PNG file, rotating IP addresses, and different user-agent strings. (confirmed by the publication itself: evidence; «The continuous, adapting wave of probing began separately, on August 3, 2026 at 1:01:05 AM EDT, using a disguised PNG file rather than the BMP from the first attempt.»)
  • The company says exploitation attempts continued throughout August, but the fix stopped all of them at the point it was designed to do so. (confirmed by the publication itself: evidence; «All of these attempts failed cleanly, at the exact point our patch intended.»)
  • After the incident, Rietta added stricter upload validation, automatic blocking of repeated scans, and centralized alerting. (confirmed by the publication itself: evidence; «tighter upload validation, automated blocking for repeat scanning attempts, and centralized alerting.»)

Publications:

score 79.9 · kind incident · revision 1 · stories st-haxddm