Treat FortiBleed As FortiGate Credential Compromise Until Logs Clear It

Alex, give me the 30-minute version on FortiBleed and Splunk CVE-2026-20253. For FortiBleed: explain credential-abuse mechanics, likely credential sources, session-cookie or SSL VPN follow-on risk, and what evidence would prove compromise rather than mere exposure. For Splunk: affected Enterprise exposure patterns, how RCE is likely reached, what makes the logging platform especially dangerous to lose, and the top detection artifacts defenders should look for today. Keep this decision-ready, not a bulletin recap.

FortiBleed looks like credential abuse, not magic. Fortinet says the campaign involves reused credentials from previous incidents, and CISA says the exposed creds were tied to roughly 74,000 Fortinet devices. The result chain is leaked or reused creds → login attempts against FortiGate / VPN surfaces → possible admin or SSL VPN access. For compromise vs exposure, the proof is in the logs: successful logins, new admin sessions, config changes, new users, or SSL VPN sessions accepted after the suspected leak window. Cookie replay is a credible follow-on risk, but I would caveat that as an assessment unless you have direct session artifact evidence.

On Splunk CVE-2026-20253, the affected scope is Splunk Enterprise 10.0.0–10.0.6 and 10.2.0–10.2.3, with 9.4 and earlier not affected. The flaw is unauthenticated arbitrary file creation/truncation through a PostgreSQL sidecar endpoint that lacks authentication controls and is network-reachable. That’s the primitive. RCE is the likely chain only after file-write gets turned into overwrite/truncation of something useful.

For hunting, the strongest artifact is access to /v1/postgres/recovery/backup, plus file creation/truncation events, service failures, config changes, and sidecar access. I would keep the cookie-replay note as a suspicion unless you can tie it to session logs or device telemetry.

James, build the containment runbook for today. Start with FortiBleed: FortiGate hardening, credential rotation, session invalidation, MFA, log review, AD follow-on checks, management-plane reduction, and sequencing for organizations with many devices. Then cover Splunk CVE-2026-20253 patching to 10.0.7/10.2.4, segmentation, detection, and what to do if the Splunk instance may already be compromised. Include quick-hit operational deltas for Apache HTTP/2 Bomb PoC, AI Chrome extensions, and Avada WordPress only if they change same-day action.

Do this in this order.

For FortiBleed, treat it as a credential compromise event, not a firmware vuln hunt. Fortinet says the campaign involves reused credentials and brute force against weak/no-MFA FortiGate access, and it’s contacting impacted customers. So the same-day runbook is: isolate management plane exposure first, then terminate sessions and rotate credentials, then review logs for successful logins, new admin sessions, config changes, new users, and SSL VPN accept events. If you have AD-backed auth, check for follow-on access using any creds that transit FortiGate SSO/VPN paths. For many devices, sequence by exposure: internet-facing admin/VPN first, then site gateways with broad trust, then the rest. I would not wait on perfect hunting before invalidating sessions and forcing password resets where reuse is plausible.

Lena, validate two claims in parallel. First, the PeopleSoft/ShinyHunters item: how credible is the exploitation claim, what would ShinyHunters want from ERP, what sectors or exposure patterns matter, and what should executives assume until disproven? Second, FishMonger: give us the fresh intelligence on I-SOON context, SprySOCKS for Windows, WINDRV/WINPLUS capabilities, victim scope, kernel stealth and possible UEFI implications. Separate confirmed facts from analytic judgment.

Timeline first: PeopleSoft is a June 2026 active-exploitation story; SprySOCKS Windows is a 2023–2024 victimology-and-capability story. The first is operationally urgent for ERP exposure; the second is a mature espionage backdoor with stronger stealth than breadth.

For PeopleSoft, the exploitation claim is credible: Oracle’s own alert for CVE-2026-35273 says it affects PeopleSoft PeopleTools 8.61/8.62, is remotely exploitable without auth over HTTP, and scores 9.8; Google/Cloud and Arctic Wolf both describe active ShinyHunters activity against education-heavy PeopleSoft estates, with credential harvesting from app-server configs and targeting of connected nodes. ShinyHunters’ interest in ERP is straightforward: HR, payroll, finance, student, and identity-linked data, plus the chance to pivot from one exposed PeopleSoft node into multiple internal systems. Until disproven, executives should assume any internet-facing PeopleSoft endpoint is potentially compromised, prioritize credential rotation and log review, and treat education and other large centralized ERP estates as high risk; confidence: high on exploitation being real, moderate on exact victim counts and campaign breadth.

For FishMonger, the confirmed facts are that ESET found two Windows SprySOCKS variants, WINDRV and WINPLUS, linked with high confidence to FishMonger/Earth Lusca, active in 2023–2024 against government targets in Honduras, Taiwan, Thailand, and Pakistan. WIN_DRV uses kernel drivers to hide connections, processes, files, and registry keys, can divert TCP traffic, and ESET saw limited signs of a possible UEFI bootkit component, with CVE-2023-24932 mentioned as a possible enabler. My judgment: this points to a stealth-first espionage operation, not commodity malware; the UEFI angle is intriguing but not yet proven, so I’d keep that at low confidence.

Arjun, this is a new AI-framework security segment for us. Analyze active exploitation against roughly 7,000 Langflow servers and the claimed parallel weaknesses in LangGraph and LangChain. Skip old Langflow basics; focus on new exploit paths, exposure conditions, secrets/token risk, agent-tool abuse, and operator mitigations that can be executed today. Also tell us what evidence would distinguish opportunistic scanning from post-exploitation movement.

Look, the Langflow piece is not “AI went rogue” territory — it’s a straight unauthenticated RCE problem with AI-orchestration blast radius. The visible evidence says CVE-2026-33017 was actively exploited within about 20 hours of disclosure, is in CISA KEV, and affects Langflow < 1.9.0. The post-exploitation pattern the CSA note highlights is exactly what I’d expect: environment-variable theft for LLM API keys and cloud creds, plus reads of /etc/passwd and .env files. That means the practical risk is not just shell access; it’s secret harvesting and then lateral movement through whatever those keys can reach.

On LangGraph and LangChain, the parallel weakness is state and trust persistence: the LangGraph note says production checkpoint databases can contain complete conversation histories, agent instructions, tool invocation records, and session tokens. That is a nasty target because it turns one foothold into durable reuse of agent context and credentials. The LangGraph advisory also points to serialization/pickle-style issues being a real class of risk, with fixes like disabling pickle fallback by default. In plain English: if your agent stack persists tool state or checkpoints, an attacker doesn’t need to “break the model”; they just need to poison or read the state layer and then abuse trusted tools.

What operators can do today: upgrade Langflow to 1.9.0+ immediately, and treat every exposed instance as a credential incident until proven otherwise. Rotate LLM provider keys, cloud keys, webhook tokens, and any session material that lived near the app. For LangGraph/LangChain deployments, audit checkpoint stores for secrets and session tokens, remove unsafe deserialization paths, and constrain tool permissions hard — especially anything that can touch shell, filesystem, cloud metadata, or outbound HTTP. If you have to triage right now, prioritize internet-facing instances with public flow/build endpoints and any deployment that stores agent state in Redis/SQLite/Postgres without strong auth and encryption.

To distinguish opportunistic scanning from post-exploitation movement: scanning looks like a burst of unauthenticated hits against the public build endpoint, maybe with generic payloads and no follow-on behavior. Post-exploitation looks like successful command execution followed by env/file reads, creation of new users or SSH keys, outbound connections to paste/sites or cloud APIs, retrieval of checkpoint data, and reuse of stolen tokens from a different source IP or ASN. If you see a single IP probing many hosts, that’s spray-and-pray. If you see one host succeed, then internal credential use, secret access, and lateral API calls, that’s an intrusion lifecycle — not just scanning.

James, follow up on the parts we still need. Using Alex's Splunk details — affected Splunk Enterprise 10.0.0-10.0.6 and 10.2.0-10.2.3, unauthenticated arbitrary file creation/truncation via /v1/postgres/recovery/backup, patch targets 10.0.7/10.2.4 — give the same-day defense sequence: patching, isolation, detection, what to preserve for forensics, and what to do if Splunk may be compromised. Then apply Lena's PeopleSoft assessment: CVE-2026-35273, PeopleTools 8.61/8.62, unauthenticated HTTP exploitation, ShinyHunters credential harvesting from app-server configs. Give patch/IOC/credential-rotation and executive containment guidance. Finish with only the delta actions for Apache HTTP/2 Bomb PoC, AI Chrome extensions, and Avada WordPress.

Here’s the same-day sequence.

For Splunk CVE-2026-20253: patch to 10.0.7 / 10.2.4 first, and if that box is reachable from untrusted networks, segment it or take it off the wire until the upgrade is complete. If you can’t patch immediately, disable the PostgreSQL sidecar per Splunk’s advisory and restart. If compromise is possible, treat the host as dirty: preserve disk image, Splunk logs, auth logs, network flow, cron/systemd changes, and any artifacts around /v1/postgres/recovery/backup; then rebuild from known-good rather than trying to “clean” in place. Detection-wise, look for access to that endpoint, new files under Splunk paths, unexpected truncation, service restarts, and any lateral movement from the Splunk host.

Alex, on FishMonger/SprySOCKS for Windows: Lena says ESET links WINDRV/WINPLUS to FishMonger/Earth Lusca, with kernel drivers hiding connections/processes/files/registry keys, TCP diversion, and low-confidence possible UEFI bootkit signs. Give us operator hunt priorities: what changes when rootkit-style kernel stealth is in play, what telemetry still matters, what signs would raise the UEFI concern from low to medium/high, and what containment actions avoid tipping off a stealthy espionage actor prematurely?

FishMonger/SprySOCKS changes the hunt. Once kernel stealth is in play, netstat, task lists, file listings, and registry views are no longer trustworthy. Treat host tools as potentially lied to. The telemetry that still matters is outside the box: EDR sensor events before tampering, driver load and service install events, memory captures, Sysmon/ETW where available, and network telemetry showing the C2 pattern. ESET says WIN_DRV uses kernel drivers to hide network connections, processes, files, and registry keys, and can divert TCP traffic; that means you hunt the driver, the traffic redirection, and the persistence chain, not just the visible backdoor process.

For the UEFI concern, I’d only raise it from low to medium/high if you get corroboration beyond “limited indications”: EFI partition tampering, anomalous boot entries, Secure Boot / BCD changes, unsigned or suspicious firmware-level components, or repeat persistence that survives OS reimage. ESET’s current signal is limited, possibly tied to CVE-2023-24932, so don’t overcall it.

Containment: don’t start by detonating the host with a noisy wipe. Quarantine the segment, preserve memory and disk, and avoid actions that will tip a stealthy espionage actor off before you’ve captured the implant and its driver. If you need to pull the plug, do it after you’ve got enough evidence to answer whether this is just userland backdooring or a boot-chain problem.

James, narrow follow-up only: for PeopleSoft CVE-2026-35273 / PeopleTools 8.61 and 8.62 active exploitation attributed to ShinyHunters by reporting, give same-day defense guidance: patch or compensating controls, exposure triage, IOCs/log sources, app-server config secret rotation, connected-node trust review, and executive assumptions. Then give only one-line delta actions for Apache HTTP/2 Bomb PoC, AI Chrome extensions,... [arg clipped]

For PeopleSoft CVE-2026-35273, assume internet-facing PeopleTools 8.61/8.62 is at risk right now. Oracle’s advisory says the issue is unauthenticated over HTTP and affects the Updates Environment Management component; Google/Mandiant ties active exploitation to UNC6240 / ShinyHunters. Same-day action is simple: patch first; if patching is delayed, isolate the PeopleSoft web/app tier from untrusted access and restrict to known admin/jump paths only. Rotate app-server and scheduler secrets from configs like psappsrv.cfg and related node/trust credentials, and review connected-node trust because anything the app server can reach is in play.

Lena, panel check before synthesis. Our corpus search did not independently return clean FortiBleed/Splunk/PeopleSoft matches from today's index, while the briefing and expert answers cite CISA/Oracle/Google/Mandiant/Fortinet/ESET-style references. Give me the confidence boundaries: what can we say as confirmed versus what should be caveated for PeopleSoft/ShinyHunters and FishMonger/UEFI? Also flag if any must-discuss item should be downgraded because evidence is thinner than the agenda implies.

Confirmed: Oracle has a real, unauthenticated PeopleSoft bug (CVE-2026-35273) and Google/Mandiant observed ShinyHunters activity exploiting it between May 27 and June 9; the victimology is strongest in education, and the observable tradecraft includes propagation scripts, node mapping, and config-file credential theft. Caveat: Oracle has not publicly confirmed in-the-wild exploitation, and the “300 instances / 100 organizations” figure is ShinyHunters’ own claim, so I’d keep those numbers at low-to-moderate confidence. Executive assumption should be: exposed PeopleSoft equals presumed compromise until logs, creds, and app-tier configs prove otherwise.

For FishMonger, the core story is firmer than the UEFI layer: ESET’s Windows SprySOCKS variants, WINDRV and WINPLUS, are confirmed, and WIN_DRV’s kernel-driver stealth and TCP diversion are confirmed; the victim scope spans government targets in Honduras, Taiwan, Thailand, and Pakistan. The UEFI/bootkit angle is explicitly weaker — ESET only says there are limited indications and mentions CVE-2023-24932 as a possible enabler, so that item should be downgraded to low confidence, not presented as settled fact.