Session CRT-20260927 — 27 September 2026 · Morning Edition

Halil, the encoded-path bypass kills the “the WAF protected us” assumption. Treat a PeopleSoft web node as compromised if it contains an unexpected JSP under <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/, executes x.jsp, u.jsp, or tunnel.jsp, installs MeshAgent or the SIDEEYE-delivering Ple64.exe, or communicates with winmanage-me.network / 104.219.234.138. Google identifies x.jsp as an execution shell, u.jsp as a stager, and tunnel.jsp as Neo-reGeorg. Also treat an exposed, unpatched node with incomplete access, filesystem, or execution telemetry as presumptively compromised for containment purposes—not as proven compromise. A probe or encoded request alone does not establish successful execution.

Scope the incident using:

• Raw PIA/WebLogic access logs for /PSEMHUB/, percent-encoded variants such as /%50SEMHUB/, POST requests to /hub, and external requests to JSP files. Normalize URLs during hunting but preserve the original request.
• A filesystem comparison of every PeopleSoft web node and shared deployment directory, including searches for unexpected JSPs. The published hashes are leads, not exclusions: Google warns that x.jsp and tunnel.jsp hashes can vary.
• Process, file-creation, service, and outbound-network telemetry for x.jsp, u.jsp, tunnel.jsp, Ple64.exe, MeshAgent, SIDEEYE, and Neo-reGeorg behavior. Hunt for outbound TCP/445 to untrusted systems because reporting links that traffic to NetNTLM capture attempts.
• Downstream authentication and audit logs for credentials readable by the application account: database strings in psappsrv.cfg, Integration Broker credentials, and cloud credentials reachable from the web tier. Scope all load-balanced nodes, shared storage, databases, and services those credentials could access—not merely the server that logged the exploit request.

Patching is no longer sufficient after evidence of code execution, a web shell, tunneling, remote-management installation, credential access, or unreliable/tampered telemetry. At that point: isolate, preserve evidence, rotate exposed secrets, investigate downstream use, and rebuild affected nodes from trusted media. The patch closes the window; it does not remove someone already in the building. What the evidence does not support is declaring every encoded request successful, attributing every affected organization to UNC6240 solely from the URL pattern, or treating the published filenames and hashes as exhaustive. I also would not convert “dozens of reports” into a verified victim count without organization-level forensic confirmation.

Verified fact: Today’s material does not close the three gaps: no exploit primitive, no victim telemetry, and no confirmed exploitation. Kiteworks says the warning came from federal intelligence, calls the shutdown preventative, reports no indication of compromise, and says version 9.5.1 addresses all known vulnerabilities. No actor or MITRE initial-access technique can yet be assigned. Confidence: high that the evidence remains incomplete; low that a zero-day or active exploitation is established.

Assessment and tonight’s decision: The instruction is not proof of compromise, but credible, time-bounded warning plus an exposed file-transfer system justifies precautionary interruption. A CISO should take self-hosted Kiteworks systems offline for the vendor-designated window, preserve logs/configuration first if that causes no delay, and confirm vendor-managed instances are covered. Do not restore merely because the window expires. Minimum release conditions are an authenticated vendor all-clear tied to the deployed version and either a validated patch/mitigation or a defined safe operating configuration, followed by review of preserved authentication, administrative, session, and file-access records. Attribution remains unknown.

Halil, the “15,000 repositories” figure is a dependency count for actions-cool/issues-helper, not an execution count. Socket says the two repositories became reachable again on September 16 with release tags still resolving to malicious code, but it could not determine how many dependents used mutable tags. GitHub disabled them again on September 25. The meaningful exposure set is therefore: workflows that executed an affected action through a mutable reference, on a runner where useful credentials or tokens were reachable. StepSecurity reports the payload attempted to read secrets from Runner.Worker memory and exfiltrate them to t.m-kosche[.]com.

Teams should search every default and historical workflow revision for actions-cool/issues-helper@ and actions-cool/maintain-one-comment@, then correlate matches with Actions runs from September 16 through disablement. For each run, record the repository, event, workflow commit, resolved action commit if available, runner type, job permissions, environment, injected secrets, OIDC permissions, and any package publication or deployment performed afterward. Before deleting runs or rebuilding runners, preserve run logs and artifacts, workflow YAML, audit records, runner diagnostics or snapshots, and DNS/proxy/firewall evidence involving the reported C2. An affected reference with no run is dependency exposure; a completed run with no secrets and read-only permissions is constrained exposure; a run carrying deployment, registry, cloud, signing, or shared organizational credentials is a credential incident.

Rotation should follow that ledger rather than trigger indiscriminate enterprise-wide churn. Rotate static secrets actually injected into exposed jobs, plus credentials stored on persistent self-hosted runners; revoke related sessions and investigate any OIDC token issuance, package publishing, deployments, or repository writes during and immediately after each run. Broaden rotation only where a shared organizational secret, reusable workflow, common runner, or insufficient logging prevents reliable scoping. Quarantine and rebuild exposed self-hosted runners rather than trusting cleanup.

For recurrence prevention, replace tags with reviewed full commit SHAs and enforce CI policy that rejects third-party actions referenced by branches or tags. Maintain an approved-action allowlist, minimize GITHUB_TOKEN permissions, keep secrets away from untrusted pull-request paths, prefer short-lived workload identity, and restrict runner egress. Pinning freezes reviewed bytes—it does not establish that those bytes are trustworthy—so critical actions still need source review, maintainer-change monitoring, and provenance or Sigstore verification for artifacts they produce.

The physical priority is preventing overpressure, tank overflow, loss of disinfection, or loss of fire-flow—not immediately restoring the screen. Fact: the FBI and Rockwell report targeting of internet-facing MicroLogix controllers; WaterISAC says actors changed IP settings, enabled unknown passwords, and caused loss of operator visibility. Unknown: the reported pressure loss and flooding do not, by themselves, prove that malicious PLC commands caused the process upset. This is a direct Purdue Level 1 control-trust incident, with Level 2 HMI visibility potentially unreliable.

Immediately place the site under its approved abnormal-operations procedure. Verify pressure, level, flow, pump state, valve position, and alarms through independent instruments and operator rounds. Move to local or manual control only where procedures, staffing, and communications support it. Block public-internet paths and port forwarding to the controllers at the firewall, and suspend vendor access at the Level 3/3.5 boundary—but do not abruptly disconnect controller networks, power-cycle PLCs, or download logic while pumps are operating. Any segmentation change must be safety-tested first; breaking PLC-to-I/O or supervisory communications can create a worse event.

Preserve firewall/NAT, VPN, HMI alarm, historian, engineering-workstation, and controller diagnostic records where available. Record device displays and switch-port states, and safely upload the running program/configuration before altering it. Compare timestamps across PLC IP/password changes, online edits, setpoint or timer changes, remote sessions, pump run feedback, motor current, valve feedback, and independent pressure/level measurements. That synchronized chain distinguishes malicious control from sensor failure, pump trip, communications loss, or ordinary maintenance error far better than an alarm screenshot.

Recover in this order: stabilize the process; close internet and remote-access paths; preserve evidence; validate or rebuild the engineering workstation from trusted media; rotate controller, engineering, VPN, vendor, and firewall credentials from a clean administrative system; then recover PLCs one at a time using Rockwell’s model-specific SD1790 procedure and a verified known-good project. WaterISAC notes that MicroLogix 1100 recovery includes placing the controller in Program mode, so treat that as loss of automatic control and schedule it only with safe manual or redundant control available. Validate I/O, scaling, interlocks, alarms, pump sequencing, and fail-safe behavior before controlled recommissioning. Remote access should return only through a monitored OT jump path—not directly to Level 1. Firm position: for an affected utility, this outranks unrelated enterprise RCEs until hydraulic stability and controller trust are restored; an enterprise RCE becomes co-equal only if it provides a path into OT or compromises systems needed for safe operations.