⚡ Daily Global Cyber Threat Intelligence Digest | July 30, 2026

Coverage window: July 29, 2026, 08:00 to July 30, 2026, 08:00 (UTC+8)
Audience: CISOs, SOC teams, Application Security, DevSecOps, AI Security, OT Security, and APAC defence teams

This edition includes only events first disclosed during the coverage window, or developments that received significant technical, official-confirmation, affected-scope, or operational-risk updates during the period.

Official security advisories, government and local-authority statements, and original research were prioritised. Vendor confirmation, public PoCs, researcher demonstrations, media follow-up, and analyst inferences are presented separately according to their respective evidence levels.

---

📝 Executive Summary — 10-Second Read

• 🔴 Ruby on Rails CVE-2026-66066 can allow an unauthenticated attacker to read arbitrary files from the server. Affected applications use Active Storage and libvips while accepting untrusted image uploads. If an attacker obtains secret_key_base, the Rails master key, database credentials, or cloud credentials, the risk may escalate to session forgery, application takeover, and lateral movement.

• 🔴 Gitea CVE-2026-60004 can turn ordinary repository write access into host command execution. An attacker can abuse the diffpatch workflow to create a Git hook in a temporary bare repository. Open registration makes it easier for an external visitor to create an account and repository independently.

• 🔴 More than 30 Minnesota community water systems were targeted in a coordinated attack. The incidents occurred on July 26–27. The key update during this window was public reporting of the overall affected scope. Current evidence does not show that every targeted system was successfully compromised.

• 🔴 The complete MCP attack chain for Ruflo CVE-2026-59726 has been disclosed in greater detail. Older default Docker Compose configurations exposed an unauthenticated MCP Bridge and MongoDB on all interfaces, potentially enabling container shell access, API-key theft, AgentDB poisoning, and conversation-data exfiltration.

• 🟠 Firefox CVE-2026-10702 is carry-over technical research. Mozilla patched the issue on June 2, while Nebula Security published the original research on July 10. The new material during this window consists mainly of further media synthesis of the implications for Firefox, Tor Browser, and an Android exploit chain.

---

🚨 Major Incidents

1. CVE-2026-66066: Rails Active Storage Arbitrary File Read Can Escalate to Application Takeover

Official disclosure date: July 29, 2026
Package: Active Storage
CVSS v4.0: 9.5 — Critical
Exploitation status: Official advisory and initial research published; full attack chain and PoC not yet disclosed
In-the-wild exploitation: No official confirmation observed
Analyst operational priority: 🔴 Critical

Rails states that applications using Active Storage and libvips while accepting untrusted image uploads may allow an attacker to trigger unsafe libvips operations through a specially crafted uploaded file.

An attacker can read arbitrary files and process-environment data accessible to the Rails process. Some affected libvips operations handle formats unrelated to ordinary Web images, so the attack payload does not necessarily need to be a normally displayable JPEG, PNG, or GIF.

Affected Conditions

An application is affected when all of the following are true:

• It uses libvips as the Active Storage image processor.
• It accepts image uploads from untrusted users.
• It runs an affected Rails/Active Storage version.

Rails specifically states:

Generating variants is not a separate requirement.

Therefore, disabling only one explicit variant-generation workflow should not be treated as a reliable fix.

Affected and Fixed Versions

Rails/Active Storage branch	Remediation
Rails 7.2	Upgrade to 7.2.3.2 or later
Rails 8.0	Upgrade to 8.0.5.1 or later
Rails 8.1	Upgrade to 8.1.3.1 or later
Rails 7.1, 7.0, 6.x, or earlier	No corresponding backport is listed for these older branches; upgrade the entire Rails stack to a supported fixed branch

Teams running older Rails versions should not replace only the activestorage gem within the existing application. Active Storage and other Rails components normally need compatible versions, so the complete Rails stack should be tested and upgraded together.

In addition, libvips must be version 8.13 or later. libvips <8.13 cannot disable unsafe unfuzzed operations, so upgrading Rails/Active Storage alone is insufficient.

Why File Read Can Cause Greater Impact

The Rails process can commonly read:

• secret_key_base.
• config/master.key or RAILS_MASTER_KEY.
• Secrets decrypted from encrypted credentials.
• Database accounts.
• S3, GCS, or Azure Storage credentials.
• Cloud workload credentials.
• SMTP credentials.
• OAuth secrets.
• Third-party API tokens.

After obtaining this information, an attacker may be able to:

• Forge or decrypt cookies.
• Take over existing sessions.
• Forge signed global IDs.
• Access Active Storage objects.
• Log directly into databases or object storage.
• Access other SaaS or cloud services.
• Chain file read into RCE under specific configurations.

Immediate Actions

1. Upgrade the Rails/Active Storage stack to a compatible fixed version.

2. Confirm that every production image, container, and worker uses libvips ≥8.13.

3. If the Rails/Active Storage stack cannot be upgraded immediately:

   • When using libvips 8.13+, set the VIPS_BLOCK_UNTRUSTED environment variable, for example:

VIPS_BLOCK_UNTRUSTED=1

• When using ruby-vips 2.2.1+, run the following in an initializer:

Vips.block_untrusted(true)

4. If using libvips <8.13:

   • Official workaround: Remove the libvips/ruby-vips dependency.
   • Emergency containment: Stop all untrusted image uploads until remediation is complete or the dependency is removed, and ensure that Web UI, API, direct-upload, and background-processing paths are all blocked.

5. Do not treat a WAF, MIME-type checks, or disabling only some variants as a complete fix.

6. After patching, treat every secret readable by the Rails process as potentially exposed and rotate:

   • secret_key_base.
   • The Rails master key.
   • Every secret stored in encrypted credentials.
   • Database credentials.
   • Cloud/object-storage credentials.
   • SMTP, OAuth, and third-party API tokens.

7. After replacing secret_key_base, expect:

   • Users to be required to sign in again.
   • Encrypted/signed cookies to become invalid.
   • Signed global IDs to become invalid.
   • Old Active Storage URLs to become invalid.

8. Do not retain the potentially exposed old secret as a fallback.

Primary Sources

• Ruby on Rails Security Announcement
• Rails GitHub Security Advisory — GHSA-xr9x-r78c-5hrm
• Ethiack — KindaRails2Shell

---

2. CVE-2026-60004: Gitea Diff Patch Can Create a Malicious Git Hook

Official advisory date: July 28, 2026
Affected versions: Gitea >=1.17, <1.27.1
Fixed version: Gitea 1.27.1
Severity: Critical
Exploitation status: Official PoC published
In-the-wild exploitation: No official confirmation observed
Analyst operational priority: 🔴 Critical for exposed or open-registration instances

Gitea’s diffpatch endpoint applies user-submitted patches inside a shared bare temporary clone.

By repeatedly submitting crafted patches, an attacker can create a Git add/add collision that causes Git’s three-way fallback to write an executable entry to:

hooks/post-index-change

Because the root of a bare repository is $GIT_DIR, this file becomes a genuine Git hook. When Git updates the index, the hook runs and executes shell commands with the privileges of the Gitea service account.

Required Exploitation Conditions

Successful exploitation requires:

• Ordinary write access to at least one repository.
• Git 2.32 or later.
• The diffpatch route to be enabled.
• A writable and executable Gitea temporary filesystem.

Open registration affects only the path for an attacker who does not already have an account. When open registration is enabled, an external visitor can create an account and repository independently, thereby obtaining write access. However, open registration is not required in every exploitation scenario.

Potential Impact

An attacker may gain access to:

• app.ini.
• Gitea application secrets.
• The process environment.
• Mounted repositories.
• Database credentials and contents.
• OAuth/SSO credentials.
• Webhook and integration secrets.
• Package-registry credentials.
• Internal services reachable by Gitea.

The official PoC does not require an outbound reverse shell. An attacker can store command output in Git objects, create a new branch containing the results, and retrieve them through authenticated smart HTTP.

Therefore, monitoring only for external C2 or reverse-shell traffic may miss the attack entirely.

Immediate Actions

1. Upgrade to Gitea 1.27.1 or later.

2. Inventory production, staging, disaster-recovery, internal-development, and test instances.

3. Before patching:

   • Disable open registration.
   • Restrict repository creation.
   • Tighten write access.
   • Restrict external access to the diffpatch API.

4. After confirming that normal Git operations are not affected, consider mounting the Gitea temporary filesystem with noexec as defence in depth before patching. This does not replace a version upgrade.

5. Hunting priority should be:

   1. Search for repeated or abnormal diffpatch requests.
   2. Search for child processes launched by the Gitea service account.
   3. Inspect abnormal Git refs, objects, branches, and commits.
   4. Check for residual temporary hooks.

6. Prioritise searches for:

POST /api/v1/repos/{owner}/{repo}/diffpatch

and, inside temporary clones:

hooks/post-index-change

7. Inspect for:

   • Repeated submission of the same executable-hook patch.
   • Shells or script interpreters launched by the Gitea process.
   • New branches used to store command output.
   • Executable files in temporary directories.
   • Unauthorised repository, administrator, token, or integration changes.

8. If compromise is suspected, rotate:

   • OAuth/SSO secrets.
   • Repository deploy keys.
   • CI/webhook tokens.
   • Package-registry credentials.
   • SMTP and database credentials.
   • Environment secrets readable by Gitea.

9. Verify that repositories, release artefacts, packages, and downstream CI/CD jobs were not tampered with.

Primary Source

• Gitea GitHub Security Advisory — GHSA-rcr6-4jqh-j84m

---

3. Minnesota: More Than 30 Community Water Systems Targeted in Coordinated Attack

Incident period: July 26–27, 2026
Major update during this window: Reuters reported at 06:35 on July 29, 2026 (UTC+8) that Minnesota IT Services had confirmed more than 30 targeted systems
Exploitation status: Investigation confirmed malicious unauthorised access within the incident cluster
Attribution status: Unconfirmed
Analyst operational priority: 🔴 High for water and OT operators

Minnesota IT Services states that more than 30 community water systems were targeted in a coordinated cyberattack during July 26–27.

Investigators confirmed malicious unauthorised access within the incident cluster, but current public information does not establish that every targeted system was successfully compromised or that all facilities experienced the same degree of OT or operational impact.

Local reporting indicates that:

• Operating controls at the Braham water plant went offline temporarily, causing a brief shutdown of wells and water-treatment facilities.
• Some automated controls in South St. Paul were affected, but operators maintained normal water and wastewater services.
• Communications with water towers and lift stations in Plymouth were affected, and operators switched to manual procedures.
• Some automated control functions in Maple Plain were affected.

At the time of public reporting, Minnesota IT Services was not aware of any active requirements for residents to change water use. Named cities including Braham, Plymouth, and Maple Plain stated that water quality or public safety was not affected. The complete status of the other targeted systems has not been published.

Attribution Limitations

The targets and some access methods resemble previous activity by Iran-affiliated actors against Internet-facing PLCs in the United States.

However:

• Minnesota authorities have not formally attributed the incidents.
• The initial-access vector has not been disclosed.
• The affected PLC/gateway vendors have not been fully identified.
• Public evidence is insufficient to link every incident to a single actor.

Target or technique similarity should therefore not be treated as evidence of Iranian attribution.

Immediate Actions

1. Inventory all:

   • Internet-facing PLCs.
   • HMIs.
   • SCADA gateways.
   • VPNs.
   • Remote Desktop services.
   • Vendor remote-maintenance systems.
   • Engineering workstations.

2. Remove direct Internet exposure from controllers and HMIs.

3. Disable:

   • Default passwords.
   • Shared accounts.
   • Dormant vendor accounts.
   • Unused remote-access services.

4. Restrict controller programming mode to approved engineering workstations only.

5. Compare the following with a known-good baseline:

   • PLC logic.
   • Set points.
   • Reusable code modules.
   • HMI screens.
   • Alarm configuration.
   • Safety settings.

6. Hunt for:

   • Unauthorised remote logins.
   • Controller-configuration changes.
   • Project uploads/downloads.
   • Unusual device restarts.
   • Alarm suppression.
   • Manual overrides.
   • New engineering-workstation connections.
   • Program Mode outside maintenance windows.

7. Validate manual operation, safe shutdown, and IT/OT isolation procedures.

8. Even if service has been restored, availability alone must not be used as the closure criterion. Verify that control logic, alarms, set points, and safety settings have not been persistently modified.

Primary Sources

• Reuters — Coordinated Attack Targets More Than 30 Minnesota Water Systems
• CBS Minnesota — Braham Water Plant Outage and Other Local Impacts

---

🤖 AI/MCP Security

4. CVE-2026-59726: Ruflo MCP Bridge Unauthenticated RCE and AgentDB Poisoning

Original advisory: July 1, 2026
Fixed version: Ruflo 3.16.3
Major update during this window: Noma Labs published the complete exploitation chain on July 29
CVSS v3.1: 10.0 — Critical
Exploitation status: Researchers validated the complete attack chain in test deployments
In-the-wild exploitation: No confirmed activity observed
Status: Technical follow-up

Default Docker Compose configurations before Ruflo 3.16.3 exposed the MCP Bridge and MongoDB on every network interface.

An unauthenticated attacker could submit tools/call directly to:

POST /mcp
POST /mcp/:group

This bypassed the tool blocklist that applied only to the autopilot flow and allowed the attacker to call:

terminal_execute

thereby obtaining a shell inside the container as the node user.

Complete Impact

After successful exploitation, an attacker may be able to:

• Read provider API keys for OpenAI, Anthropic, Google, OpenRouter, and others.
• Use the victim’s API keys to create attacker-controlled agents.
• Read conversations, memory, titles, and metadata.
• Modify system prompts or tool definitions.
• Write malicious AgentDB patterns.
• Poison subsequent agent outputs.
• Access MongoDB when authentication is not configured.
• Use agent tools to access repositories, hosts, or external services.
• Establish persistence that survives a container restart in the researchers’ test environment.

The final item is an attack path demonstrated by researchers in a specific test deployment. It does not mean that every successful exploitation will necessarily create the same persistence.

Remediation Changes

The main changes in Ruflo 3.16.3 include:

• The MCP Bridge binds only to loopback by default.
• Public binding without MCP_AUTH_TOKEN fails closed.
• Bearer-token authentication.
• terminal_execute disabled by default.
• MongoDB authentication required by default.
• Read-only container filesystem and tmpfs.
• CORS allowlist.
• CI regression checks.

Immediate Actions

1. Upgrade to Ruflo 3.16.3 or later.
2. Block the following from untrusted networks:

TCP 3001
TCP 27017

3. Confirm that the MCP Bridge, MongoDB, and other management endpoints are not bound to:

0.0.0.0

4. Enforce the following for every MCP request:

   • Strong authentication.
   • Tool-level authorisation.
   • Network allowlists.
   • Request logging.
   • Rate limiting.
   • Explicit policies for high-risk tools.

5. Disable the following by default:

   • terminal_execute.
   • Filesystem write access.
   • Credential access.
   • Shell execution.
   • Unapproved network tools.

6. Rotate credentials readable by the Ruflo container, including:

   • Model-provider API keys.
   • GitHub/GitLab tokens.
   • Cloud credentials.
   • SSH keys.
   • Database credentials.

7. Inspect AgentDB for:

   • agentdb_pattern-store.
   • New or abnormal patterns.
   • Poisoned entries affecting all users’ outputs.
   • Unapproved learning artefacts.

8. Inspect MongoDB for:

   • Unauthorised data changes.
   • Conversation/memory access.
   • New users or authentication changes.
   • Abnormal exports.
   • Persistence artefacts.

9. Hunt for:

   • New shell tools inside the container.
   • MongoDB clients or payloads in /tmp.
   • Unexpected outbound connections.
   • Modified prompts, tools, or configuration.
   • Abnormal processes that reappear after a container restart.

10. Do not merely redeploy the patched version. A patched redeployment does not automatically delete injected AgentDB patterns, revoke exposed API keys, or restore tampered MongoDB data.

Primary Sources

• Ruflo GitHub Security Advisory — GHSA-c4hm-4h84-2cf3
• Noma Labs — RufRoot Technical Research

---

🧪 Carry-Over Technical Research

5. CVE-2026-10702: Firefox JIT Vulnerability and Android Root Chain

Mozilla patch date: June 2, 2026
Original research date: July 10, 2026
Update during this window: Further media synthesis of the complete exploit chain on July 29
Mozilla severity: High
Minimum fixed version: Firefox 151.0.3
In-the-wild exploitation: No official confirmation observed
Status: Carry-over/media amplification

Mozilla describes CVE-2026-10702 as a miscompilation issue in the Firefox JavaScript Engine JIT component and patched it in Firefox 151.0.3 on June 2.

Nebula Security published IonStack Part I on July 10, demonstrating how the JIT flaw could be weaponised to obtain arbitrary code execution inside the Firefox content/renderer process.

The public Android 17 attack chain also requires a separate Linux kernel futex vulnerability to obtain root. Therefore:

CVE-2026-10702 is the browser entry point, not a complete device-takeover vulnerability by itself.

Evidence Boundaries for Firefox and Tor Browser

• The Mozilla advisory lists only Firefox.
• The Nebula research involves browser builds using the relevant Firefox code path.
• Tor Browser uses Firefox ESR and selectively backports security fixes.
• It is not valid to infer that every Tor Browser version is affected merely because Tor Browser is based on Firefox.

Tor Browser 15.0.19 upgraded to Firefox ESR 140.13.0 on July 21 and backported Firefox 153 security fixes. The actual security status should be determined from Tor Project release notes.

Recommended Actions

• Firefox users should upgrade to Mozilla’s current latest supported stable or ESR release.
• Firefox 151.0.3 is only the minimum fixed version for this CVE, not the current final upgrade target.
• Tor Browser users should upgrade to the current latest Tor Project release.
• Confirm that the browser has restarted so that a downloaded update does not leave an older process running.
• Shorten browser patch SLAs for security researchers, journalists, diplomats, human-rights workers, and highly privileged administrators.

Primary Sources

• Mozilla Foundation Security Advisory 2026-54
• Nebula Security — IonStack Part I
• Tor Project — Tor Browser 15.0.19
• The Hacker News — Exploit-Chain Follow-up

---

🔐 Data Breaches/Ransomware

Across the official corporate disclosures, government/regulatory filings, and primary threat-intelligence sources reviewed, no newly confirmed major data breach or significant ransomware incident was identified within the coverage window.

Some ransomware sites added victim names, but without company confirmation, regulatory filings, verifiable data samples, or credible incident-response evidence, this edition does not present them as confirmed incidents.

---

👀 Developments to Watch

• Rails CVE-2026-66066: Rails states that complete technical details will be published no later than August 28. Watch for PoCs, scanning, arbitrary-file-read activity, and secret-exfiltration telemetry.
• Gitea CVE-2026-60004: Whether mass scanning, bulk exploitation of open-registration instances, or a CISA KEV update emerges.
• Minnesota water-sector incidents: The proportion of successful compromises, the initial-access vector, equipment vendors, control-logic changes, and formal attribution.
• Ruflo/MCP: Whether TCP 3001/27017 remains publicly exposed, and whether other agent frameworks contain the same unauthenticated high-privilege tool design.
• Firefox CVE-2026-10702: Whether in-the-wild exploitation appears or the research chain is ported to other architectures and browser builds.
• CISA KEV: Based on the editorial team’s review as of July 30, 2026, 08:00 (UTC+8), no new entries were identified during this window. The most recent confirmed update was the July 27 addition of Fortinet CVE-2025-68686 and Arista CVE-2026-16812.

KEV References

• CISA Known Exploited Vulnerabilities Catalogue
• NVD — CVE-2025-68686
• NVD — CVE-2026-16812

---

✅ Today’s Priority Actions

P0 | Immediate

1. Identify every Rails application that uses Active Storage and libvips while accepting untrusted image uploads.
2. Upgrade the Rails stack to a supported fixed release and confirm libvips ≥8.13.
3. Upgrade every Gitea instance to 1.27.1 or later.
4. Block publicly exposed Ruflo TCP 3001/27017 and upgrade to 3.16.3 or later.
5. Begin compromise assessments for Rails, Gitea, and Ruflo deployments that were publicly exposed.

P1 | Next 24–72 Hours

1. Rotate every secret readable by the Rails process and revoke old sessions.
2. Hunt for Gitea diffpatch requests, service-account child processes, and abnormal Git objects.
3. Investigate Ruflo AgentDB, MongoDB, conversation stores, and provider API-key usage.
4. In Minnesota and other water-sector OT environments, compare PLC logic, set points, and alarm configuration against a known-good baseline.
5. Require high-risk Firefox/Tor Browser users to complete the update and restart the browser.

P2 | Within This Week

1. Build a complete inventory of the following high-risk services:

   • File-upload processors.
   • Self-hosted code platforms.
   • MCP servers.
   • Agent memory stores.
   • Internet-facing OT systems.
   • High-risk browser populations.

2. For self-hosted development and AI platforms, record:

   • Registration policy.
   • Authentication.
   • Network exposure.
   • Executable tools.
   • Stored secrets.
   • Temporary-filesystem permissions.
   • Downstream privileges.

3. Make “patching + secret rotation + data-integrity verification” the standard remediation process for arbitrary-file-read vulnerabilities and control-plane RCE.

4. Apply the same identity, authorisation, network-isolation, and audit controls to MCP servers as to production administrative APIs.

5. Conduct Internet-exposure reviews, logic-baseline verification, and manual-operation exercises for OT environments.

---

📌 Final Assessment

The incidents in this coverage window show that attackers do not necessarily need to defeat complex identity controls directly.

They can:

• Use an image processor to read application secrets.
• Turn ordinary repository write access into shell execution through Git functionality.
• Use an unauthenticated MCP endpoint to obtain high-privilege tools.
• Exploit publicly exposed OT remote access to affect physical operations.
• Use a single malicious Web page to establish a browser foothold.

Today’s most important defensive conclusion is:

Do not assess only whether an entry point requires authentication. Determine whether low-privilege functionality can reach the execution environment, secrets, tools, temporary directories, and downstream control planes.

Patching closes only the known entry point. For Rails, Gitea, Ruflo, or OT systems that were publicly exposed, organisations must also rotate secrets, verify data integrity, check for persistence, and re-establish the trustworthiness of downstream environments.