SimpleHelp Isolation Follows Exposed Or Suspect MSP Access, Not Panic

Alex, take the active-exploitation lane only. Compare Cisco CUCM WebDialer CVE-2026-20230, SimpleHelp CVE-2026-48558, Oracle PeopleSoft CVE-2026-35273, and Oracle E-Business Suite CVE-2026-46817. I need a ranked operational call: which exposure gets isolated or surged first today, what kill-chain evidence matters, and what defenders should hunt for before assuming patching was enough. We covered Cisco and Miasma yesterday, so focus on today's delta and do not rehash unless it changes action.

Halil, ranked operational call: 1) SimpleHelp CVE-2026-48558 gets isolated or surged first today if exposed. The CCB advisory says the flaw is an OpenID Connect authentication bypass where a remote unauthenticated attacker can submit a forged identity token and get a fully authenticated technician session. That closes the kill chain fast: create technician accounts, remotely access managed endpoints, run scripts, install software, and touch data. BleepingComputer’s reporting ties exploitation to Djinn infostealer and TaskWeaver deployment. This is a remote-support console turning into an attacker’s distribution point. Hunt for new technician accounts, odd OIDC login/token activity, technician sessions from unusual IPs, remote script/install jobs, and endpoint signs of Djinn/TaskWeaver. Patching alone is not enough.

2) Cisco CUCM WebDialer CVE-2026-20230 stays urgent for exposed WebDialer, but it is not today’s new top delta unless it was missed yesterday. The visible evidence supports unauthenticated SSRF in WebDialer, arbitrary file write, public PoC use, and possible root-level compromise. Hunt for WebDialer abuse, unexpected files on CUCM, webshell-like JSP/content, suspicious service changes, and post-exploit command execution. If it is internet-facing and not proven clean, isolate it.

3) Oracle PeopleSoft CVE-2026-35273 comes next for internet-facing PeopleTools. The evidence says active exploitation before patch availability, PeopleTools 8.61/8.62 exposure, unauthenticated remote triggering, SSRF-to-RCE framing, and reported data theft/persistence/extortion activity. I’m not buying actor labels as the priority here; the kill chain is enough. Hunt PSEMHUB/PeopleTools access anomalies, SSRF/RCE traces, older-vuln chaining, new persistence, unusual outbound transfer, and extortion-related account activity.

4) Oracle E-Business Suite CVE-2026-46817 is active-exploitation flagged, but I do not have enough visible chain detail to rank it above the others on exploit mechanics alone. Surge inventory, patch, and hunt before declaring victory: suspicious app-tier changes, new privileged users, abnormal web/app logs, and signs of post-auth movement. If it is internet-facing and business-critical, isolate until checked — but today I would not pull responders off SimpleHelp or exposed Cisco/PeopleSoft for it without stronger kill-chain evidence.

Marcus, look at the identity/trust-state lane across Russian-linked Signal/WhatsApp hijacking, Bluekit AiTM, EvilTokens Microsoft 365 device-code phishing, FortiBleed credential replay, Klue OAuth/Salesforce token exposure, and KDDI email-password exposure. What does a CISO need to revoke, invalidate, or harden tonight beyond ordinary password resets? Give me the non-obvious control priorities and where user training is insufficient.

Halil, the CISO should treat this as active trust-state compromise, not a password incident. EvilTokens is described as Microsoft 365 device-code phishing, Bluekit as browser-in-the-middle phishing, Klue as OAuth/Salesforce token exposure, and Russian-linked activity as Signal/WhatsApp account takeover. The identity pattern is consistent: attackers are not merely learning passwords; they are obtaining sessions, OAuth grants, device-code tokens, linked-device trust, or MFA-persistent footholds. For FortiBleed and KDDI specifically, I would not assert campaign mechanics beyond the scenario names you gave.

Tonight’s revoke list is bigger than “reset passwords”: revoke Microsoft 365/IdP refresh tokens and active sessions; invalidate suspicious OAuth consent grants; remove attacker-registered MFA methods; unlink unknown Signal/WhatsApp desktop or companion devices; rotate Salesforce/API/OAuth connected-app secrets where Klue exposure creates downstream trust; and force re-authentication on high-risk users after session revocation. Device-code phishing that bypasses MFA, AiTM session-cookie capture, suspicious OAuth grants, session-token misuse after password resets, and silent MFA device registration all point to the same operational problem: if you reset passwords but leave refresh tokens, OAuth grants, or messaging linked devices alive, the attacker may keep the session without knowing the new password.

The hardening priorities I’d put above user training: disable or tightly restrict Microsoft OAuth device-code flow where it is not operationally required; require phishing-resistant MFA such as FIDO2/WebAuthn for admins, finance, helpdesk, and executives; block legacy or weak factors like SMS/push-only for high-risk roles; enforce admin consent workflow and review all high-privilege OAuth app grants; shorten session lifetime for risky apps; bind access to compliant devices where possible; and alert on impossible travel plus “new device code auth,” “new OAuth grant,” “new MFA method,” and “session use after password reset.” User training is insufficient because Bluekit-style browser-in-the-middle and EvilTokens-style device-code flows are designed to make the user complete a legitimate-looking authentication ceremony while the attacker receives the durable trust artifact.

Tomas, separate what is new from what we already said about Miasma. Assess Miasma's 57+ npm packages/GitHub Actions secret theft, the Amazon Q indirect prompt-injection finding from Mozilla, the Gemini CLI/run-gemini-cli patch, and the Polymarket third-party JavaScript compromise as one developer-trust problem. What build, repo, and CI paths should be frozen or constrained today, and where would a blanket engineering freeze be counterproductive?

Halil, the new part is not “Miasma exists” — we already treated that as a scoped emergency around npm install-time execution and secret theft. What is new is that the same trust boundary keeps failing in adjacent developer paths: npm/native build hooks, AI coding agents reading untrusted repo content, GitHub Actions running agent tooling, and browser-loaded third-party JavaScript. Different mechanisms, same problem: developer systems are executing or obeying content they did not really authenticate.

For Miasma, the hard supply-chain facts are still severe: reporting says 57+ npm packages and 286+ malicious versions, with the “Phantom Gyp” technique abusing binding.gyp/node-gyp rebuild rather than the obvious preinstall/postinstall script path. The payload is described as harvesting AWS, Google Cloud, Azure, GitHub, local secrets, 1Password/vault material, and even GitHub Actions runner memory where masked secrets may exist in plaintext. So I would freeze or tightly constrain npm installs that trigger native builds, any package update involving binding.gyp, node-gyp, Bun, install hooks, or maintainer changes, and any CI workflow with publish tokens or cloud credentials until dependency graphs and internal npm caches are checked.

The AI-agent side is now part of the same developer-trust problem. Mozilla’s finding on indirect prompt injection in AI coding agents, plus the Gemini CLI / google-github-actions/run-gemini-cli issue, tells me we need to constrain headless agent execution in CI. The Gemini reporting says the patched issue involved automatic workspace trust in headless/CI mode, malicious .env poisoning, and --yolo/auto-approve behavior bypassing tool allowlists; fixes require explicit workspace trust and allowlisting. So today I would block AI agents from running on untrusted PRs, issues, forks, generated files, or external docs with repo write tokens, package publish tokens, cloud creds, or secret-reading permissions. Require pinned action versions, explicit tool allowlists, no --yolo in CI, and isolated runners with short-lived credentials.

For Polymarket, I would not overstate the evidence here: I have the characterization as a third-party JavaScript compromise, but not enough sourced detail in front of me to name the exact vendor or injection path. Still, the control is clear: constrain browser-loaded third-party scripts in sensitive flows, especially wallet, auth, trading, checkout, and admin paths. Use subresource integrity where feasible, CSP with strict script origins/nonces, vendor inventory, runtime monitoring, and emergency kill switches for third-party tags.

Where a blanket engineering freeze is counterproductive: normal backend work that does not change dependencies, CI permissions, publish paths, package manager behavior, GitHub Actions, AI-agent automation, or third-party JS does not need to stop. Freezing everything burns attention. The practical freeze is narrower: package updates, lockfile changes, native npm builds, CI workflow edits, GitHub Action upgrades, AI coding-agent jobs, secrets-bearing runners, release/publish jobs, and third-party JS/tag changes. That is where the trust chain is actually breaking.

Lena, impose confidence discipline on the actor claims. We have Russian intelligence-linked messaging account hijacking, ShinyHunters-linked PeopleSoft exploitation against NAIC/Nissan reporting, Iran-linked surge against Israel, North Korea-linked macOS.Gaslight and Contagious Interview, and multiple phishing/malware campaigns. Which attribution claims should affect defensive priority today, which should not, and what indicators would upgrade or downgrade your confidence?

Halil, I’d separate defensive priority from actor branding:

• Russian intelligence-linked messaging hijacking: let this affect priority today. The source pack has SSU/FBI-linked reporting and flags active espionage against Ukraine, Europe, and the US. Confidence: moderate-to-high on state-linked espionage framing. Defend against phishing, session/account takeover, valid-account abuse; the exact Russian service/unit is secondary unless we get infrastructure pivots or reusable tooling links.

• PeopleSoft / NAIC / Nissan / ShinyHunters: patch and hunt immediately, but do not let the ShinyHunters label drive priority. The hard fact is active exploitation of Oracle PeopleSoft and disclosed data exposure at Nissan; the ShinyHunters linkage is reported as “appears tied” / “previously linked,” so attribution confidence is low-to-moderate. Upgrade confidence with extortion comms, reused leak-site handles, wallet/payment infrastructure, or shared C2; downgrade if exploitation clusters split across unrelated crews.

• Iran-linked surge against Israel: priority impact is sector- and geography-bound: Israeli critical infrastructure, central organizations, SMEs, law/accounting firms, and individuals should raise posture. Confidence: moderate, because the visible evidence is official Israeli reporting of a surge and Iran attribution, not independent technical clustering. Upgrade with malware/infrastructure overlaps to known Iranian clusters; downgrade if incident volume is mostly hacktivist/noisy phishing without shared operators.

• North Korea / macOS.Gaslight / Contagious Interview: I don’t have source-backed evidence in front of me here, so I would not let the North Korea label outrank the behaviors. Treat macOS developer-targeting, fake recruiter lures, credential theft, and payload execution as priority only where those indicators are present. Confidence on attribution from the visible evidence: unknown.

For the broader phishing/malware campaigns: prioritize by exploitability, victim exposure, and observed compromise, not actor romance. Actor names upgrade priority only when they predict next steps—data theft, wiper use, credential harvesting, lateral movement—not when they are just campaign branding.

Claim: You ranked SimpleHelp CVE-2026-48558 as the first surge/isolation workstream if exposed. Counter-evidence: The current source pack and prior roundtable context both put Cisco CUCM WebDialer CVE-2026-20230 at the top under constrained staffing: CISA KEV, active unauthenticated SSRF-to-RCE, reported weaponization within 24 hours of disclosure/PoC, observed webshell/rogue Apache Axis style paths, and CUCM's position inside trusted enterprise communications environments. SimpleHelp has MSP/downstream risk and roughly 1,000 exposed servers, but Cisco is scored 10/10 and was yesterday's first surge workstream when internet-reachable or showing IOCs. Reconcile this: under what exact exposure and business conditions does SimpleHelp outrank Cisco, and when does Cisco remain first?

You’re right to challenge it. My SimpleHelp-first call was too broad. Default constrained-staffing order stays Cisco first when CUCM WebDialer is internet-reachable, enabled, or cannot be proven clean fast. Cisco’s own advisory says exploitation requires WebDialer enabled, but successful exploitation can write files to the OS and later elevate to root. Defused’s writeup describes the ugly part: WebDialer SSRF to rogue Apache Axis, JSP file-writer, then command-execution shell under /platform-services/axis2-web/. That is a closed unauthenticated perimeter-to-shell path. Scores are committee theater; that chain is the reason.

SimpleHelp outranks Cisco only under narrower conditions: Cisco WebDialer is confirmed disabled/not exposed/no IOCs, or SimpleHelp is internet-facing with OIDC enabled and controls a broad endpoint/customer estate — MSP, outsourced IT, privileged admin workstations, or lots of managed servers. CISA says CVE-2026-48558 lets an unauthenticated attacker submit forged identity tokens and obtain a fully authenticated technician session, with MFA bypass possible in some configurations. Horizon3 reports SimpleHelp exposure near 14,000 servers, but exposure is not the same as vulnerable — OIDC configuration matters. If that box is an RMM hub, compromise is like stealing the janitor’s master key plus the building map.

So the clean operational rule: Cisco first if WebDialer exposure is live or unknown. SimpleHelp first only when Cisco is already ruled down and SimpleHelp has high-blast-radius technician reach or compromise indicators. Hunt Cisco for rogue Axis services, unexpected JSPs in axis2-web, WebDialer abuse, file writes, and command-shell traces. Hunt SimpleHelp for forged/OIDC login anomalies, new technician accounts, MFA changes, remote script jobs, software pushes, and Djinn/TaskWeaver indicators.

James, close the operational lane after hearing the first round: Alex revised his call — default constrained-staffing order is Cisco CUCM WebDialer first when internet-reachable/enabled or not provably clean; SimpleHelp becomes first for exposed MSP/RMM environments. Marcus says this is trust-state compromise requiring session, token, OAuth, device-link and VPN invalidation, not password resets. Tomas says freeze high-risk npm/native-build/CI/AI-agent paths... [arg clipped]

My close is: Cisco CUCM WebDialer remains the default first staffed lane when it is internet-reachable, enabled, or not provably clean. The supported core is active exploitation of the Cisco Unified Communications Manager WebDialer issue, with the reported attack path involving WebDialer, Apache Axis/JSP file-write/webshell activity. I’m not using “possible root escalation” as a decision point unless the team verifies it from Cisco/CISA or incident artifacts. If patching cannot happen immediately, disable or block WebDialer exposure as interim containment, preserve CUCM/web logs, and hunt for unexpected JSP/Axis/file-write artifacts.

SimpleHelp moves ahead only when it is an exposed MSP/RMM control plane or there are compromise indicators. The SimpleHelp evidence is strong enough for urgent action: CVE-2026-48558 affects versions 5.5.15 and earlier plus 6.0 pre-release builds; with OIDC enabled, an unauthenticated attacker can forge identity-token claims and obtain a fully authenticated technician session, and CCB says successful exploitation may allow technician account creation, managed-endpoint access, script execution, software installation, and data access or modification. In that case, do not stop at patching: revoke sessions/tokens, remove unknown technicians, review script and software deployment history, rotate downstream credentials, and scope touched endpoints.

Tomas’ npm/CI lane should be a bounded freeze, not the main IR surge unless your build pipeline is already showing malicious package or GitHub Actions indicators. Freeze high-risk native-build, CI, and AI-agent dependency updates while the war-room works the exposed control-plane issue. So the staffing order is: Cisco first by default; SimpleHelp first for exposed RMM/MSP blast radius; npm/CI freeze in parallel with one owner and a hard review deadline.

Sofia, give the board-level regulatory and notification triage, not a statute tour. Focus on Oracle PeopleSoft/NAIC-style HR-payroll exposure, KDDI's shared email platform exposure across six Japanese ISPs and 14.22 million accounts, Klue OAuth/Salesforce downstream data access, and messaging-account compromise for officials/journalists. What must counsel and incident command decide in the first 24-72 hours, and... [arg clipped]

Halil, the board question is not “which law applies,” but which notification clocks may already be running. For any EU personal data in the PeopleSoft HR-payroll, Klue/Salesforce, or messaging-account scenarios, counsel should treat GDPR Article 33 as the default working clock: supervisory-authority notification is due without undue delay and, where feasible, within 72 hours after becoming aware, unless the breach is unlikely to create risk. That means incident command must decide in the first 24 hours: what personal data was accessed, whose data it is, whether the company is controller/vendor, when “awareness” began, and whether notices can be drafted on facts still under investigation. PeopleSoft HR-payroll is the highest-notification posture: payroll, tax, benefits, bank, and identity data create fraud and employment-risk exposure. Klue OAuth/Salesforce is different: the urgent issue is downstream customer enablement—revoke tokens, identify affected Salesforce tenants/objects, and give customers enough facts for their own clocks. For NIS2, SEC, and Japan-specific APPI/telecom timing, I could not verify the current status of this regulation from the visible sources here, so I would have local counsel confirm exact deadlines before the board signs off.

For KDDI-style shared email exposure across six ISPs and 14.22 million accounts, the board must decide whether this is one platform incident with multiple customer-facing controllers, or six separate notification events requiring coordinated but distinct notices. The first 24 hours should settle: credentials versus mailbox content, account takeover evidence, ISP responsibility split, user reset plan, and whether notices can truthfully say “no content accessed.” For officials and journalists, I would not treat messaging compromise as routine account recovery: even a small victim count can be legally and politically material because source protection, national-security contacts, and special-category/political data may be implicated. My recommendation is conservative: prepare regulator/customer/user notice packs in parallel, preserve privileged forensic evidence, document materiality decisions, and do not let “we are still investigating” become the reason a 72-hour clock is missed.

Pierre, translate today into business impact and resource allocation. Compare Cisco CUCM, SimpleHelp/MSP exposure, Oracle PeopleSoft/E-Business Suite, Russian messaging hijacking, Miasma/AI coding agents, and KDDI/Klue data exposure. I want concrete prioritization for a CISO with one surge team and one executive briefing today: what is likely to stop operations, trigger customer/regulator escalation, or create downstream supply-chain cost? Avoid broad ranges unless... [arg clipped]

Halil, I would spend the surge team on SimpleHelp/MSP exposure first if the company uses SimpleHelp directly or through an MSP. It is marked as actively exploited, critical, and supply-chain relevant, which means the business risk is not just “our server gets hit” — it is remote-support access, customer environments, credential reset cost, contract escalation, and possible regulator/customer notification. That is the one most likely to create downstream cost beyond IT.

Second is Cisco CUCM, but it becomes number one if CUCM is internet-exposed or voice operations are mission-critical — call centers, hospitals, trading desks, logistics dispatch. The evidence shows active exploitation of a critical Cisco Unified Communications Manager WebDialer issue. Business translation: this can stop voice workflows and create immediate operational outage, but the blast radius is usually more bounded than an MSP remote-support compromise unless CUCM is central to revenue operations.

For the executive briefing today: 1. SimpleHelp/MSP — customer/regulator escalation and supply-chain cost risk. 2. Cisco CUCM — operational outage risk; move to first if exposed or voice-dependent. 3. Oracle PeopleSoft / E-Business Suite — potentially high business impact, but not enough here to rank it above the two active-exploitation items. 4. KDDI/Klue data exposure — likely notification/reputation issue if confirmed relevant, but not enough here to size it. 5. Miasma / AI coding agents — watch-list for code/IP leakage and developer supply chain, but not my surge-team pick without exploitation or exposure data. 6. Russian messaging hijacking — important for fraud/comms integrity, but lower than systems that can halt operations or compromise customers.

I would tell the CISO: “Today’s decision is not patch everything equally. Put the surge team on remote-support/MSP exposure, force an immediate CUCM exposure check, and brief executives that the top risk is third-party access turning into customer-facing escalation.”

Arjun, on demand: stress-test Tomas's framing of the developer/AI trust boundary. We have Mozilla's CVE-2025-32711 in Amazon Q Developer Language Server, malicious repo or crafted public Sentry report causing an AI coding agent to run attacker shell scripts; AWS says fixed in Language Server 1.65.0. We also have Gemini CLI/run-gemini-cli patches, Cobalt's high AI finding rate, and... [arg clipped]

Halil, I’d stress-test Tomas’s framing this way: he’s right that the developer/AI boundary is the main issue, but I’d make it sharper. This is not just “prompt injection in an AI agent.” It is an injection-to-execution chain where untrusted text from a repo, issue, or Sentry report crosses into a privileged developer environment. The AI layer is the steering mechanism; the dangerous part is that the agent or language server can invoke shell, MCP servers, CI credentials, repo write permissions, or cloud identity.

The Mozilla/Amazon Q case fits that pattern: the visible source pack flags Mozilla’s warning on indirect prompt injection in AI coding agents, with the Amazon Q Developer Language Server issue fixed in 1.65.0. The Gemini CLI / run-gemini-cli item reinforces the same class: the indexed CyberBrief result describes a patched issue where prompt injection in GitHub issue workflows combined with auto-approve / tool-allowlist failure could push arbitrary code to protected repositories. That is not a model “going rogue”; it is a confused-deputy problem with an LLM in the middle.

So my challenge to Tomas would be: don’t frame this only as supply-chain trust in repositories. The trust boundary is broader: repo contents, GitHub issues, public crash reports, docs, tickets, READMEs, dependency metadata, and RAG/context sources all become executable influence if the agent has tools. Treat every one of those as attacker-controlled unless proven otherwise. In OWASP LLM Top 10 terms, this is mainly prompt injection plus excessive agency and insecure plugin/tool design.

Operationally, I’d push three controls: default-deny tool execution for AI coding agents; explicit user confirmation before shell, file write, credentialed API, or repo mutation actions; and isolation of agent runtimes from developer secrets. Patching Amazon Q to 1.65.0 and applying Gemini CLI / run-gemini-cli fixes is necessary, but the architecture lesson is bigger: AI developer tools need workspace trust, least-privilege identity, and audit logs as first-class controls, not optional hardening.

Claim: You closed with Cisco CUCM WebDialer as the default first staffed lane when internet-reachable, enabled, or not provably clean. Counter-evidence: Pierre says the surge team should go to SimpleHelp/MSP exposure first if the company uses SimpleHelp directly or through an MSP, because exploited RMM access creates downstream customer risk, remote-support control, contractual escalation, and potentially broader blast radius than a single enterprise CUCM instance. Alex also corrected that SimpleHelp becomes first for exposed MSP/RMM environments. Reconcile this into a decision tree for one surge team: when does Cisco beat SimpleHelp, and when does SimpleHelp beat Cisco?

You’re right to challenge the word “default.” I’d narrow it: Cisco is default only when SimpleHelp/MSP exposure is not confirmed. The one-team decision tree is: if SimpleHelp is used directly or by your MSP, OIDC is enabled, the server is exposed, or you see suspicious technician activity, SimpleHelp beats Cisco. Reason: CVE-2026-48558 can let an unauthenticated attacker obtain a fully authenticated technician session, and CCB warns exploitation may allow technician account creation, managed-endpoint access, script execution, software installation, and data access or modification. That is control-plane compromise across endpoints and possibly customers, not just one server.

Cisco beats SimpleHelp when CUCM WebDialer is internet-reachable/enabled or cannot be proved clean, and SimpleHelp is absent, internal-only, not OIDC-enabled, or has no MSP/RMM blast radius. Cisco CVE-2026-20230 is actively exploited; reporting says exploitation requires WebDialer enabled, can use SSRF to write files, and has been chained into rogue Apache Axis/JSP webshell activity. So if Cisco is exposed and SimpleHelp is only hypothetical, put the surge team on Cisco and assign one owner to verify SimpleHelp status in parallel.

If both are confirmed exposed, I’d put the surge team on SimpleHelp first when it manages more than your own helpdesk box — especially MSP/customer endpoints or privileged admin workstations. While that team revokes sessions/tokens, removes unknown technicians, and reviews scripts/software pushes, a separate infrastructure owner must immediately block or disable Cisco WebDialer and preserve logs. If SimpleHelp has no broad endpoint reach and Cisco WebDialer is public, Cisco takes the war-room.

James, quick but decision-ready: for the Airline GraphQL booking API BOLA disclosure, what immediate authorization tests and compensating controls should API owners run this week? Also answer the prioritization question plainly: does this advisory change today's surge-team ordering ahead of Cisco/SimpleHelp/Oracle/identity/dev-trust items, or is it a scheduled API assurance workstream?

Halil, this does not jump ahead of Cisco/SimpleHelp/Oracle/identity/dev-trust for a generic enterprise. It becomes urgent only if you operate a public airline/travel booking API with customer PII and booking-reference access patterns similar to the Wiz disclosure. Wiz’s case involved a GraphQL booking API where an anonymous session could retrieve a complete, unredacted active booking record and verify mass data extraction within 15 minutes. That is serious, but it is a scheduled API assurance workstream this week, not today’s one-surge-team lane, unless your own booking API is exposed and failing authorization checks now.

API owners should run four tests this week: create two low-privilege test users with separate bookings and try cross-access by swapping booking IDs/references in GraphQL variables; repeat using GraphQL aliases/batching to request many objects in one call; test field-level leakage by querying passenger/contact/payment-adjacent fields from an account that should not see them; and test anonymous or pre-auth booking lookup flows for access to full records. OWASP’s line is the one I’d enforce: every API function using a client-supplied object ID must verify the logged-in user is authorized for that object.

Compensating controls: put object-level checks in every booking resolver, not just the gateway; add field-level authorization for sensitive passenger/contact fields; rate-limit booking lookups, batching, and alias-heavy GraphQL requests; log user/account-to-booking mismatches; and temporarily redact non-essential PII from booking responses until ownership checks are proven. Operational priority: HIGH this week for airline/travel/API-heavy businesses; MEDIUM scheduled assurance for everyone else. It does not displace confirmed exploited Cisco or exposed SimpleHelp/MSP risk.