Iran-Linked Water Sector Cyber Concerns and Critical Rails, Wazuh, FreeRDP Flaws Lead August 2 Threat Digest
TL;DR - Multiple states reported cyberattacks as U.S. officials reportedly suspect Iran is targeting water systems. - Rails, Wazuh, FreeRDP, and a WordPress plugin disclosed severe flaws needing fast triage. - Prioritize internet-exposed systems, CI/CD runners, admin accounts, and remote access clients today.
Top Stories
Suspected Iran targeting of water systems raises operational risk for states and utilities
The Washington Post reports that several states are dealing with cyberattacks while spy agencies suspect Iran is targeting water infrastructure (Washington Post via Google News.
So what?
Even without full public IOCs, this matters for more than utilities. Water operators, municipalities, managed service providers, OT integrators, and SMBs supporting public infrastructure should expect elevated scanning, credential attacks, phishing, and attempts to access remote administration paths.
What defenders should do next - Review remote access paths into SCADA, HMI, VPN, firewall, and jump hosts. - Audit accounts with access to water or industrial environments, especially contractors and shared admin identities. - Verify MFA is enforced on all remote admin access. - Check whether internet-exposed HMIs, remote desktop services, or vendor support portals are reachable externally. - Prepare for disruptive, not just data-theft, scenarios: lockouts, controller misconfiguration, or process interruption.
Rails patches critical Active Storage flaw with possible RCE path
BleepingComputer reports that Rails patched a critical Active Storage vulnerability that can allow arbitrary file reads and could potentially be escalated to remote code execution in some deployments (BleepingComputer).
So what?
If you run Rails applications that expose file upload, transformation, preview, or attachment processing, this is a high-priority patch cycle item. The biggest risk is usually internet-facing apps with permissive upload workflows and background processing components.
What defenders should do next - Patch Rails and any affected gems or components immediately according to upstream guidance. - Review any public upload endpoints and attachment preview features. - Search for anomalous file access patterns around app worker processes. - Rotate credentials reachable by the Rails app if compromise is suspected. - Add temporary compensating controls if patching must wait: WAF rules, endpoint restrictions, disabling risky processing paths.
Technical Notes
Example triage commands for a Linux-hosted Rails app:
# Identify Rails version
bundle exec rails -v
# List active gems related to storage and processing
bundle list | egrep 'rails|activestorage|image_processing|mini_magick|vips'
# Search for suspicious file access and processing errors
grep -R "ActiveStorage\|MiniMagick\|Vips\|Errno::\|No such file" log/ /var/log/ 2>/dev/null
Useful review points in logs:
Started POST "/rails/active_storage/direct_uploads"
Processing by ActiveStorage::*
Completed 500 Internal Server Error
ActionController::RoutingError
Errno::ENOENT
Critical Vulnerabilities
CVE-2026-67308: Wazuh workflows shell injection in GitHub Actions
A Wazuh advisory describes a shell injection vulnerability in workflows before commit 44bf114, where crafted VERSION.json content in pull requests could lead to command execution inside GitHub Actions and possible secret exfiltration, including GITHUB_TOKEN and cloud credentials on self-hosted runners (GitHub advisory, VulnCheck summary).
Why it matters - This is especially serious for organizations using self-hosted runners. - CI/CD compromise can pivot into source code, package pipelines, cloud environments, and release signing workflows. - Pull request automation from forks is a common weak point.
Immediate actions - Update to a fixed workflow version or commit baseline. - Disable or restrict workflows triggered from forks until review is complete. - Remove secrets from contexts exposed to untrusted pull requests. - Review self-hosted runner isolation, egress controls, and credential scope.
Technical Notes
Quick GitHub Actions review:
# Find risky direct interpolation patterns in workflows
grep -R '\${{.*}}' .github/workflows | grep 'run:'
grep -R 'VERSION.json\|pull_request_target\|pull_request' .github/workflows
Example risky pattern to review:
steps:
- name: Read version
run: echo "VERSION=$(jq -r .version VERSION.json)" >> $GITHUB_ENV
- name: Use version
run: make release VERSION="$VERSION"
Safer approach: - Treat PR-controlled input as untrusted. - Avoid shell interpolation of user-controlled values. - Use explicit validation before passing data to shell commands.
# Example input validation
VERSION="$(jq -r .version VERSION.json)"
printf '%s' "$VERSION" | grep -Eq '^[0-9A-Za-z._-]+$' || exit 1
CVE-2026-67330: @better-auth/scim authorization bypass
The @better-auth/scim plugin had an authorization bypass affecting versions >= 1.4.0-beta.27 through <= 1.6.21 and >= 1.7.0-beta.0 through <= 1.7.0-beta.9. According to the advisory, provider ID collisions could let an authenticated user mint a SCIM token that resolved to accounts the token never provisioned, enabling unauthorized user listing, updates, deletions, session impacts, and account takeover. Fixed in 1.6.22 and 1.7.0-beta.10 / 1.7.0-rc.0 (GitHub advisory, VulnCheck summary).
Why it matters - Identity infrastructure bugs are high impact because they affect provisioning and account integrity. - This can turn into stealthy user tampering, session deletion, or admin account takeover.
Immediate actions - Upgrade to a fixed version. - Review SCIM integrations, provider IDs, and token issuance logs. - Audit recent user updates, deprovisioning events, and session deletions. - Reset SCIM bearer tokens if there is any sign of abuse.
Technical Notes
Review package versions:
npm ls @better-auth/scim
pnpm why @better-auth/scim
yarn why @better-auth/scim
Look for suspicious SCIM activity in application logs:
/scim/v2/Users
/scim/v2/Groups
PATCH /Users/
DELETE /Users/
token issued
providerId=
CVE-2026-15964: WordPress Single Sign On For TNG authentication bypass
The WordPress plugin Single Sign On For TNG is described as vulnerable to unauthenticated password reset in versions up to and including 2.0.0. The issue stems from a password reset path exposed through wp_ajax_nopriv_ssoprocess_ajax, where a publicly accessible nonce is not an authorization control and an attacker can reset arbitrary account passwords, including administrator accounts (plugin code reference 1, reference 2, reference 3, reference 4, changeset).
Why it matters - This is a direct path to full site takeover if the plugin is enabled. - Shared hosting and smaller organizations are especially exposed because admin log review is often weak.
Immediate actions - Disable the plugin if no fixed version is available and the feature is not mission-critical. - Reset all administrator passwords. - Invalidate active sessions. - Review for unauthorized admin creation, password changes, content edits, and plugin/theme modifications.
Technical Notes
Quick checks for a WordPress host:
# Find plugin version
grep "Version:" wp-content/plugins/single-sign-on-for-tng/single-sign-on-for-tng.php
# Look for recent admin user changes
wp user list --role=administrator
wp option get active_plugins
Review web logs for abuse of the AJAX action:
grep -R "admin-ajax.php" /var/log/apache2 /var/log/nginx 2>/dev/null | grep "ssoprocess_ajax"
Suspicious request shape:
POST /wp-admin/admin-ajax.php
action=ssoprocess_ajax
operations=setnewpassword
email=admin@example.com
CVE-2026-66402: FreeRDP TLS certificate identity validation weaknesses
FreeRDP before 3.29.0 contains multiple certificate identity validation weaknesses, including SAN parsing and hostname matching issues that could weaken server authentication when an attacker can present a trusted or misissued certificate (commit, GitHub advisory, VulnCheck summary).
CVE-2026-67289: FreeRDP HTTP proxy request injection via redirection
A separate FreeRDP issue before 3.29.0 allows CRLF and control characters in a redirection field to be copied into proxy CONNECT requests, enabling arbitrary header or request injection when the client uses an HTTP proxy (commit, GitHub advisory, VulnCheck summary).
Why these matter together - FreeRDP is often used in admin workflows, jump boxes, VDI access, and Linux-based help desk environments. - Combined trust and proxy handling issues raise the risk of MITM-like abuse, redirection misuse, and proxy manipulation.
Immediate actions
- Upgrade FreeRDP to 3.29.0 or later.
- Review whether users connect to RDP servers through HTTP proxies.
- Revisit certificate trust settings and any permissive connection flags.
- Restrict outbound proxy usage for admin workstations where possible.
Technical Notes
Check installed version:
xfreerdp /version
dpkg -l | grep freerdp
rpm -qa | grep freerdp
Look for risky invocation patterns in scripts or shell history:
grep -R "xfreerdp" /usr/local/bin /opt /home 2>/dev/null
Examples to review:
xfreerdp /v:server.example /cert:ignore
xfreerdp /v:10.0.0.12 /proxy:http://proxy.local:8080
If “/cert:ignore” is common in your environment, fix that operationally as well as technically.
What Defenders Should Do Today
1) Raise monitoring for water, municipal, and OT-adjacent environments
Focus on: - VPN concentrators - remote desktop gateways - firewall admin portals - engineering workstations - vendor remote support tools - identity providers tied to operators and contractors
Practical checks: - Review logins outside normal shifts. - Alert on new MFA device registration. - Flag impossible travel and repeated password reset events. - Check for configuration changes on PLC, HMI, and remote access systems.
Technical Notes
Example hunting queries and commands:
# Search auth logs for remote admin activity
grep -Ei "sshd|sudo|vpn|rdp|mfa|radius" /var/log/auth.log /var/log/secure 2>/dev/null
# List listening remote access services
ss -tulpn | egrep ':(22|443|3389|5900|8443)\b'
2) Patch the highest-risk internet-facing and identity-connected systems first
Prioritized patch order for many teams today:
1. Rails applications with Active Storage exposure
2. FreeRDP clients on admin and support endpoints
3. Wazuh CI/CD workflow definitions and self-hosted runners
4. @better-auth/scim deployments
5. WordPress sites using the affected SSO plugin
If patching cannot happen immediately: - disable risky features - block public access where possible - rotate credentials in scope - add temporary detection rules
3) Review CI/CD trust boundaries
The Wazuh case is a reminder that CI pipelines are part of production security.
Minimum controls: - no secrets in workflows triggered by untrusted forks - ephemeral runners where possible - restricted cloud IAM roles for runners - outbound egress filtering from build infrastructure - approval gates for release workflows
Technical Notes
Basic repository review checklist:
# Find workflows that may run in unsafe contexts
grep -R "pull_request_target\|workflow_run\|repository_dispatch" .github/workflows
# Find secret references
grep -R "secrets\." .github/workflows
4) Reconfirm admin account hygiene
Several items in today’s digest have account takeover implications.
Do today: - reset passwords for exposed admin accounts where compromise is plausible - force logout or invalidate sessions - verify break-glass accounts - audit newly created privileged identities - review API tokens and service credentials issued in the last 7 days
5) Brief users on likely lure themes
For organizations tied to public services or critical infrastructure, warn users about: - urgent outage notices - fake regulator or state agency contacts - password reset prompts - vendor support requests - shared document lures tied to incidents
Keep the guidance short and operational: verify out-of-band before taking action.
Bottom Line
Today’s most important takeaway is the mix of real-world operational targeting and high-severity software flaws. The reported concern around water sector targeting increases the urgency for critical infrastructure and public-sector defenders, while the Rails, Wazuh, FreeRDP, identity, and WordPress issues give attackers multiple practical entry points.
If you only have time for a short list today: - harden and monitor remote access into water or OT-connected environments, - patch Rails and FreeRDP quickly, - lock down GitHub Actions exposure to untrusted pull requests, - review SCIM and WordPress admin paths for abuse.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.