The Hacker Diaries — Featuring Jennifer Hudsen: Case File No. 048

Case-board summary

Risk at a glance

Dossier one: Chainalysis and the half-lit room

Chainalysis’s notice is short enough to read twice and still leave empty chairs around the table. The company says it detected an external actor using what it called “offensive agentic techniques” to gain unauthorized access to systems and internal tools during October 2026.[1] That phrase is attribution-free vendor language. It does not identify a model, framework, autonomous workflow, vulnerability, or initial-access method. Calling this a proven “AI agent attack” would make the label carry more weight than the published evidence.

The fields Chainalysis says were accessed are customer user IDs, full names, email addresses, and organization role labels for provisioned users.[1] Those fields are not passwords, but they are useful props. A caller can name the right analyst, the right organization, and the right role before asking for an urgent reset or an authentication approval. The practical danger is context-rich social engineering, not a magical conversion of an email address into account access.

Based on evidence available at disclosure, Chainalysis said it found no indication of access to investigation graphs, notes, cases, transaction or query results, clear-text passwords, MFA secrets, or session tokens.[1] The wording matters: “no indication” is a preliminary negative finding, not a guarantee that access was impossible. The company was still determining which organization-specific records were accessed, while the number of affected organizations, users, and records remained unpublished.[1][2]

Timeline and exposure

• During October: the vendor says the external actor gained access; the public notice does not give the first day, dwell time, or containment instant.[1]
• October 30: Chainalysis published its incident information and said vulnerabilities had been patched and systems hardened.[1]
• October 31: independent reporting recorded direct spokesperson confirmation, but no public technical report established the entry path, tools reached, or duration.[2]

The exposure test is narrower than “does my company use cryptocurrency?” Ask whether your organization had provisioned Chainalysis users and whether the vendor’s promised record-specific notice names them. Notification of every customer is not the same thing as proof that every customer’s records were accessed. Keep those denominators separate.[1]

Observed, inferred, and unknown

Detection and defensive action

Build detection around what the exposed fields enable. Flag Chainalysis-themed password-reset messages, unusual help-desk requests naming internal roles, unexpected MFA prompts, and new login geography or device fingerprints on accounts identified by the notice. Preserve the original message and headers rather than forwarding a screenshot alone. CISA advises that when a suspicious message might be real, the recipient should avoid its links and phone numbers and verify through a separately obtained channel.[3]

Do not reset every unrelated credential merely because an incident happened. Ask Chainalysis for the organization-specific record breakdown, inventory named users, brief the service desk, and require a second channel for sensitive identity or access changes. If local evidence shows that a user entered credentials, approved a prompt, or handed over a recovery code, treat that account as a separate suspected compromise and follow its identity-provider response process.[1]

Recovery line

Recovery here is mostly identity defense unless local evidence shows a successful phish. Retain every notice, document the affected field set, record which staff were warned, and watch for targeted lures. If an account is suspected compromised, reset from a known-clean device, terminate active sessions, review authentication history, and inspect downstream access granted to that identity. Do not hunt for ARTEX or block unrelated AI tools: the public notice supplies neither that attribution nor a product-specific IOC.[1]

Dossier two: Ivanti, three locks and one open gate

This is the board’s live wire. Volexity investigated a Connect Secure 22.8R2.4 appliance that was fully patched at the time and says repeated exploitation began October 3, 2026.[8] A later press quote placed the earliest confirmed activity on October 1, but the formal incident report uses October 3. The honest timeline keeps both surfaces distinct rather than polishing them into one date.

The chain’s effect was remote, unauthenticated command execution as root, but the CVEs do not each provide that capability on their own. CVE-2026-104935 supplies the initial remote, unauthenticated path; CVE-2026-111357 is a local privilege-escalation flaw; and CVE-2026-118527 is a low-privilege predictable-filename upload weakness.[7][9][10][11] The initial foothold satisfies prerequisites for the later steps. That is what makes the chain more dangerous than reading three standalone scores in isolation.

Timeline

Affected versions and the patch trap

Ivanti’s current complete-chain target is 25.1.1.3 or later; 22.8R2.6 fixes all three disclosed flaws but is a temporary bridge toward the 22.8 end-of-life date of January 31, 2027.[7] The October 13 releases 25.1.1.2 and 22.8R2.5 fixed CVE-2026-104935 but remained affected by the later-disclosed components. A version check that stops at “we installed the October patch” can therefore produce a dangerous green light.

CVE-2026-104935 is published at 8.6 High, while CVE-2026-111357 has materially different vendor and MITRE CNA assessments rather than one score that can be averaged.[7][9][10] CVE-2026-118527 was still RESERVED on the official CVE surface at the cutoff even though Ivanti had published details and CISA had placed it in KEV.[6][7][11] Reserved does not mean fake; it means the public CNA record had not yet supplied its final detail.

What was observed

Volexity reports credential extraction, limited Active Directory metadata exfiltration, searches for LAPS passwords and BitLocker recovery material, password spraying, packet capture, internal reconnaissance, and evidence cleanup.[8] It says no first-stage malware, web shell, or persistent backdoor was seen on the appliance; the actor reused the exploit channel. CISA separately says it is aware of exploitation for credential theft and data exfiltration, and Ivanti says a limited but unquantified number of customers were affected.[5][7]

Volexity’s actor label UTA0576 is a tracking name, not a real-world identity. Its suggestion of criminal purpose is low confidence, and its assessment of LLM use is medium-confidence inference. The operation was interrupted before the ultimate objective became clear. Keep those confidence labels attached; noir does not excuse turning shadows into suspects.[8]

Detection: assume disk can lie by omission

CISA and Volexity warn that a clean Integrity Checker result is insufficient because the observed activity could execute in memory, restore altered state, and remove relevant evidence.[5][8] Hunt for unusual appliance web-request bursts or mismatches, temporary artifacts, network sniffing, LDAP and directory reconnaissance, password spraying, lateral activity sourced from the appliance, and unexplained authentication changes. Any one signal may be benign; the sequence and timing matter.

Before destructive remediation, preserve memory, network telemetry, logs, configuration, process and activity timelines, and appliance provenance under incident-response control where feasible. If the organization lacks the ability to capture volatile evidence safely, do not improvise on the production edge device. Escalate to the vendor, an incident-response provider, or the appropriate security team while restricting exposure through an approved containment plan.[5]

Recovery

CISA’s response path calls for configuration backup, factory reset and upgrade of physical appliances, rebuild and upgrade of cloud or virtual instances, configuration restoration, password resets, certificate revocation and reissue, and rotation of stored API and license-server credentials when compromise is suspected.[5] Perform secret rotation from a trusted system, not from the suspect appliance. Scope every HA node, old replica, cloud deployment, and forgotten management interface. Confirm no retired instance remains reachable.

Patching shuts the known door; it does not erase credentials that may already have left through it. Review domain, administrator, local-account, API, certificate, and service credentials accessible to the device. Monitor authentication, directory, edge, and network telemetry after the rebuild. The finish line is not a screenshot of a new version number; it is evidence that the vulnerable path is closed and the downstream identity risk has been addressed.[5][8]

Dossier three: the ChatGPT share that talked through the wall

This file is a laboratory case, not a street report. Parameter says a crafted public ChatGPT conversation could execute attacker-controlled JavaScript in a signed-in viewer’s chatgpt.com context, enumerate recent conversations, read a separate private conversation, and send a deliberately small selection to researcher-controlled infrastructure.[12] The accounts and workspaces were controlled by the researchers. No victim count, campaign, actor, or unique IOC was published.

The most stable path required the recipient to open the share and press the ordinary Preview control once. Parameter also reproduced an automatic-Preview variant three times in another account, including after a hard refresh, where opening the shared link was the only user action.[12] Three reproductions establish that the variant worked in that setup; they do not establish population-wide reliability.

How the boundary failed, without a recipe

The isolated Preview frame did not simply reach through its sandbox. The reported chain used an adjacent trusted component: a cross-frame receiver in the main page accepted a state-changing message without adequately authenticating both the sender’s origin and expected window, then allowed supplied markup to reach an unsafe HTML sink. A dynamically created same-origin document and an allowlisted script route completed execution. CSA’s analysis agrees that the sandbox itself held and describes the broader problem as unauthenticated cross-frame messaging, an unsafe HTML sink, an unsandboxed dynamic frame, and an overly permissive host allowlist.[13]

That distinction changes the remedy. Removing one script route would have broken one proof but left the trust-boundary failure alive. Defenders building web applications should validate both message origin and source window, avoid passing untrusted cross-window data into raw HTML, keep dynamic untrusted documents sandboxed, and treat Content Security Policy as a backstop rather than a sanitizer.[12][13]

Timeline and status

• Oct. 13–17: Parameter says it moved from confirming the cross-frame path to reproducing manual and automatic share delivery in controlled accounts.[12]
• Oct. 18: the team submitted the report through OpenAI’s Bugcrowd program.[12]
• Oct. 21: Parameter says OpenAI reproduced JavaScript execution and the private-conversation proof and escalated triage from P2 to P1.[12]
• Oct. 26: Parameter reports that both web-frontend variants rejected the relevant messages, the issue was resolved, and the total award was $5,000.[12]
• Oct. 28: Parameter published the disclosure.[12]

The reported fix, P1 triage, two-frontend rollout, and bounty amount come from Parameter’s account of private bug-bounty handling, not from a public OpenAI security advisory.[12][13] That does not make the account false; it sets the verification ceiling. The issue was hosted and server-side, so there is no local client patch or affected-build matrix in the public record.

Observed versus extrapolated

User and administrator actions

OpenAI advises users to confirm that a shared link uses the chatgpt.com domain and comes from a trusted sender before opening it, and documents a Report conversation path.[14] A correct domain defeats lookalikes, but it would not by itself have made attacker-authored content safe before the reported fix. Treat public shares as untrusted input even on a genuine host.

Users can review links they created under Settings → Data controls → Shared links → Manage and delete individual or all links.[14] This reduces continuing disclosure of their own snapshots; it is not remediation for having viewed somebody else’s share. If a user opened a suspicious share before October 26 and sees unfamiliar activity, preserve the URL and opening time, note the browser, device, account, and workspace, and review security history and sessions.

OpenAI warns that enabling MFA does not cancel existing logins and directs users who suspect compromise to change the password, log out all sessions, and then enable MFA.[15] MFA remains good hardening, but it would not stop script already acting inside a valid browser session. Session termination and activity review are the relevant controls when this specific compromise is suspected.

Enterprise and Edu administrators can manage share-chat permissions when the control is available, while OpenAI says Business links stay inside the originating workspace but lack the Enterprise-wide disable control.[16][17] Administrators should document which control actually exists in their plan instead of assuming every workspace has the same switch. Review suspicious pre-fix activity proportionately; no public retrospective detector can prove that a normal current session list means the chain never ran.

Dossier four: Cloudflare’s quarter of swarms

The headline numbers arrive in trench coats and invite readers to add them together. Don’t. Cloudflare says it autonomously mitigated 18.2 million network-layer DDoS attack events and 14.4 trillion HTTP DDoS requests in Q3 2026.[18] The first is an L3/L4 event count; the second is an L7 request count. A request is not an attack event, and the two measurements cannot be summed into one “total attacks” number.

Using Cloudflare’s rounded baselines, 18.2 million is about 37.9% above Q2’s 13.2 million and about 208.5% above Q3 2025’s 5.9 million, while 14.4 trillion HTTP requests is about 14.8% below Q2’s 16.9 trillion.[18][19] The arithmetic is straightforward, but the data remains Cloudflare’s own network telemetry. It is not a global internet census and was not independently audited.

Many short events, fewer giants

Cloudflare reports that 96% of its network-layer events ended within ten minutes, 98% stayed below 1 Gbps, and 251 exceeded 1 Tbps, down from 805 in Q2.[18] The decline from 805 to 251 is about 68.8%, but 251 extreme events are not zero. A separate Mirai-classified event reportedly lasted 49.7 hours, which is the long tail hiding behind the short-event majority.[18]

Cloudflare prints an average near 8,226 network-layer events per hour from a less-rounded underlying count. That is a provider-wide quarterly average, not a forecast for one company and not a steady cadence. Monthly shares imply August ran much hotter than July. A small business should not buy capacity by dividing a global-looking rate into its own traffic; it should test its actual bottlenecks and provider commitments.[23]

The denominator board

The report does not publish the event-delimitation rule, customer exposure denominator, false-positive rate, or customer-impact distribution. “Mitigated” does not tell us time to mitigation, packet loss, latency, downtime, or business loss. Target rankings also lack enough method detail to turn them into a local forecast.[18]

Botnets and causality

The Justice Department confirms a March 19 operation to disrupt command-and-control infrastructure used by Aisuru, KimWolf, JackSkid, and Mossad.[20] Cloudflare suggests enforcement may have contributed to fewer hyper-volumetric events, but timing does not establish cause. The Q2 spike occurred after the March operation, and replacement ecosystems continued to appear.

Shadowserver separately reported information on about 296,000 Dysphoria-compromised devices, and FortiGuard documented a Mirai-derived DDoS engine in Evooo1Bot with activity against internet-facing devices since July.[21][22] Those sources confirm a living botnet ecosystem. They do not validate Cloudflare’s quarterly counts, byte totals, vector shares, or causal theory.

Detection and readiness

CISA distinguishes volumetric, protocol, and application-layer denial-of-service attacks, so a readiness review must cover bandwidth, packets, connection state, DNS, TLS, application workers, queues, databases, and third-party dependencies.[23] Baseline flow, WAF, CDN, DNS, origin, and application metrics with synchronized time. Define who owns each bottleneck: your staff, ISP, CDN, cloud host, DNS provider, payment vendor, or SaaS supplier.

The UK NCSC recommends understanding ISP mitigations, considering third-party DDoS protection or a CDN, and cloaking origins so traffic cannot simply bypass the protected edge.[24] Verify whether protection is always-on, automatic, or manually invoked; document alerting, thresholds, activation time, re-enable procedures, bandwidth or sinkhole behavior, and excess-usage charges. A contract’s word “protection” is not a runbook.

Recovery from an availability event

During an incident, preserve provider tickets and time-stamped metrics, classify which layer is failing, and keep an out-of-band route to the mitigation provider. Apply preapproved degradation modes rather than making emergency architecture changes blind. After service returns, reconcile detection time, activation time, traffic path, origin exposure, user impact, and any abandoned safeguards. Report significant incidents through the appropriate national or law-enforcement channel.[23]

The good news is that upstream automation can absorb enormous traffic. The bad news is that every architecture still has a narrow place: an exposed origin, a state table, a DNS dependency, a login endpoint, or an expensive query. The uncertainty is how Cloudflare defines and distributes its event counts. Plan from your own service map, not from a vendor quarter’s biggest integer.[23]

Cross-case analysis: four failures, four different clocks

These stories share a dark palette but not one remedy. The Chainalysis clock is an identity-abuse clock: exposed names, addresses, user IDs, and role labels can retain social-engineering value after the vendor closes its internal door. The Ivanti clock is both volatile and durable: memory evidence may disappear quickly, while stolen credentials and directory knowledge can remain useful after an appliance is patched. The ChatGPT clock is retrospective: the specific hosted defect is reported fixed, yet a user with suspicious pre-fix exposure still has to decide whether unfamiliar activity deserves an account review. The DDoS clock is measured in seconds: a short flood can end before a human completes the first escalation call.[5]

That difference is why “patch, reset passwords, and monitor” is not a universal plan. For Chainalysis, a blanket reset can create noise without addressing the most likely follow-on problem, which is a convincing request aimed at the help desk or a named user. For Ivanti, patching without forensic scoping can preserve availability while missing evidence that a credential or certificate has already crossed the boundary. For the ChatGPT case, password changes without terminating sessions can leave the response incomplete. For DDoS, waiting to negotiate provider activation during the event can turn a technical flood into an avoidable business outage.[23]

The identity thread

Three of the four files touch identity from different directions. Chainalysis exposed identity context. The Ivanti actor reportedly searched for credentials and directory secrets after gaining edge access.[8] Parameter’s proof acted through a browser session that was already authenticated.[12] The useful control is therefore not merely “use MFA.” It is to know where sessions live, which systems can read or relay secrets, how support staff verify sensitive requests, which credentials an edge appliance stores, and how quickly administrators can terminate or rotate them from a trusted system.

MFA is strongest at the authentication boundary. It cannot make a user ignore a tailored lure, remove a token already active in a browser, or recall a certificate copied before a rebuild. Session visibility, phishing-resistant factors, help-desk verification, least privilege, short-lived credentials, and tested revocation are companion controls. No single control earns a detective’s final line.[12]

The evidence thread

Each file also demonstrates a different evidence ceiling. Chainalysis provides a vendor notice without a public forensic appendix. Ivanti has a vendor advisory, a government exploited-vulnerability record, and a detailed incident-response reconstruction. The ChatGPT case has a technically rich researcher report and specialist analysis, but no public OpenAI advisory naming the flaw. Cloudflare supplies enormous first-party telemetry without the denominator and delimiter detail needed to generalize it to every network. Readers should expect confidence to change with that evidence stack.[12]

A practical incident register should capture that ceiling explicitly. Record whether a statement is vendor-reported, government-listed, observed by an incident responder, demonstrated in controlled testing, derived arithmetically, or inferred for planning. Then record what would change the decision: an organization-specific breach notice, a newly found Ivanti instance, unfamiliar account history, an origin IP exposed in DNS, or provider confirmation that mitigation is not automatic. This turns uncertainty into a review condition instead of a vague reason to postpone action.[5]

Defensive response flow

1. Confirm the exposure predicate. Product, version, date, account state, reachable surface, and relevant notice come before panic.
2. Preserve the evidence that will disappear. For Ivanti that includes volatile memory and network context; for phishing and shared links it includes message headers, URLs, times, sessions, and security history; for DDoS it includes synchronized provider and origin telemetry.[5]
3. Contain by mechanism. Remove vulnerable edge exposure[5], terminate suspect sessions[12], verify sensitive requests out of band[3], or activate upstream mitigation[23]. Avoid generic rituals that do not interrupt the documented path.
4. Recover from a trusted point. Rebuild or reset compromised appliances, rotate exposed secrets from clean systems, restore reviewed configurations, and validate origins and dependencies.[5]
5. Monitor the consequences, not only the door. A patch does not recall stolen credentials[5]; a password change without session termination may leave access alive[12]; a CDN does not protect an exposed origin[24].

Tonight: the short checklist

• Ivanti owners: inventory every Connect Secure instance and HA node; record exact versions; isolate any affected reachable build; preserve volatile evidence before reset where feasible; move to a complete-chain fixed release.[5][7][8]
• Chainalysis customers: retain the notice, request organization-specific affected records, warn named users and the help desk about tailored impersonation, and verify sensitive requests through a separate channel.[1][3]
• ChatGPT users: if you opened a suspicious share before October 26 and see unfamiliar activity, preserve details, review sessions and security history, and follow the compromise workflow; do not reset every account absent an exposure signal.[12][15]
• Public-service owners: confirm the DDoS escalation contact, activation mode, protected hostnames and origins, and one out-of-band communication path.[23][24]
• Everyone: write down what remains unknown. Unknown is a status to manage, not a blank to fill with confidence.

This week: make the fixes durable

• Run a full edge inventory that includes virtual appliances, cloud images, HA partners, management interfaces, and retired replicas.[5]
• Tabletop a compromise where the first device is both a gateway and a credential vantage point. Include evidence capture, identity scoping, certificate and API-key rotation, and rebuild ownership.[5][8]
• Review public-sharing policy for AI tools. Document which workspace plans can disable sharing, how users delete their own links, and how suspicious activity is escalated.[14][16][17]
• Test DDoS controls across bandwidth, packet rate, requests per second, connection state, DNS, login, search, and database-heavy paths. Confirm graceful degradation and administrative access.[23]
• Teach the service desk to resist context-rich impersonation. A caller knowing a staff member’s role is not proof of identity.[1]
• Update the incident register with source, cutoff, exposure decision, evidence retained, containment taken, recovery validation, owner, and next review date.

For local organizations that need help turning these checks into an owned plan, The IT Guys’ canonical Small Business Services page describes the support surface. Readers can use Search Articles for prior guidance or compare this board with Case File 047. Those links are local service and archive context, not evidence for tonight’s external claims.

FAQ

Does the Chainalysis notice mean my password was stolen?

No. Chainalysis says it found no indication of clear-text password, MFA-secret, or session-token access at the disclosure cutoff.[1] That is a preliminary vendor finding. Use your organization-specific notice and local account evidence to decide response scope.

Does “offensive agentic techniques” prove an autonomous AI conducted the breach?

No. It is the vendor’s phrase. No public model, framework, agent transcript, toolchain, or technical forensic report establishes how automation was used.[1]

If an Ivanti appliance now shows a fixed version, are we finished?

No. A fixed build closes the disclosed entry path; it does not prove the device was never exploited or that stolen secrets were not used elsewhere. CISA calls for network and memory forensics when compromise is suspected.[5]

Why not trust a clean Integrity Checker result?

Because the investigated chain could operate in memory and remove or restore evidence. Use the checker as one input, not as a retrospective acquittal.[5][8]

Was the ChatGPT shared-link issue exploited in the wild?

No public evidence of real-world exploitation was located in the reviewed disclosures. That means “not reported by the cutoff,” not “impossible” or “never happened.”[12][13]

Should every ChatGPT user reset a password?

No. The specific defect is researcher-reported as fixed server-side, and there is no evidence basis for universal resets. Users with suspicious pre-fix exposure or unfamiliar activity should preserve evidence and follow OpenAI’s compromise steps.[12][15]

Would MFA have stopped the shared-link chain?

Not once code was acting inside an already authenticated session. MFA is still valuable, but session review and logout matter for suspected live-session abuse.[12][15]

Did the internet suffer 18.2 million attacks?

That wording is too broad. The figure is Cloudflare’s count of network-layer events it says it mitigated on its own network. The report does not provide a global denominator.[18]

Can 18.2 million and 14.4 trillion be combined?

No. One measures network-layer events and the other HTTP requests. Combining them would add unlike units.[18]

Do fewer one-terabit attacks mean DDoS risk fell?

Not by itself. Cloudflare reports fewer such events than in Q2, but overall network event count rose, and one reported event lasted 49.7 hours. Your exposure depends on architecture, automation, provider capacity, and tested response.[18][23][24]

Methodology and transparency

This case file was assembled from the four frozen research briefs supplied for the October 31 cutoff. Primary vendor, government, official CVE, researcher, and incident-response sources were preferred for load-bearing claims. Independent reporting was used to bound what the primary parties did not disclose. The discovery headlines were not copied, and their prose is not the basis of this article.

“Observed in the wild” is reserved for public evidence of real incidents or a government/vendor active-exploitation finding.[5][8] “Lab-demonstrated” means a researcher reports controlled execution against accounts it controlled.[12][13] “Company telemetry” means measurements from a provider’s own vantage point, not an independently audited census.[18] “Unknown” stays unknown when a source is silent.[1]

Derived percentages use the rounded values published by the source and are labeled as arithmetic, not new telemetry.[18][19] Consequential factual clauses carry numbered citations immediately after the clause. Guidance is tied to CISA, NCSC, vendor, or incident-response recommendations where available; editorial synthesis is framed as practical guidance rather than a guarantee.

No local incident is claimed. The local relevance is operational: small organizations also depend on identity-rich SaaS, internet-facing gateways, shared AI workspaces, DNS, CDNs, and upstream providers. The article contains no exploit payload, request path, malicious filename, or reproduction recipe. It was transparently drafted with AI assistance under Jennifer Hudsen’s editorial identity, with source and claim ledgers created for review.

Sources

1. Chainalysis Security Incident Information — Primary Vendor Incident Notice; accessed 2026-10-31T23:34:14Z.
2. Chainalysis discloses data breach from ‘offensive agentic techniques’ — Independent News Report; accessed 2026-10-31T23:34:14Z.
3. Recognize and Report Phishing — Government Guidance; accessed 2026-10-31T23:34:14Z.
4. CISA Adds Two Known Exploited Vulnerabilities to Catalog — Government Alert; accessed 2026-10-31T23:34:14Z.
5. CISA Urges Patching Newly Exploited Vulnerabilities in Ivanti Connect Secure — Government Alert; accessed 2026-10-31T23:34:14Z.
6. CISA Catalog of Known Exploited Vulnerabilities — Government Structured Feed; accessed 2026-10-31T23:34:14Z.
7. Security Advisory Ivanti Connect Secure (CVE-2026-104935) — Primary Vendor Advisory; accessed 2026-10-31T23:34:14Z.
8. A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days — Primary Incident Response Research; accessed 2026-10-31T23:34:14Z.
9. CVE Record: CVE-2026-104935 — Official Cve Record; accessed 2026-10-31T23:34:14Z.
10. CVE Record: CVE-2026-111357 — Official Cve Record; accessed 2026-10-31T23:34:14Z.
11. CVE Record: CVE-2026-118527 — Official Cve Record; accessed 2026-10-31T23:34:14Z.
12. Do the Math: How We Took Over ChatGPT Accounts — Primary Researcher Disclosure; accessed 2026-10-31T23:34:14Z.
13. One Click Into Someone Else’s ChatGPT: Cross-Frame Messaging Flaws — Independent Specialist Analysis; accessed 2026-10-31T23:34:14Z.
14. Sharing conversations and scheduled tasks in ChatGPT — Primary Vendor Guidance; accessed 2026-10-31T23:34:14Z.
15. Keeping your OpenAI account secure — Primary Vendor Guidance; accessed 2026-10-31T23:34:14Z.
16. ChatGPT Shared Links FAQ (Enterprise Version) — Primary Vendor Guidance; accessed 2026-10-31T23:34:14Z.
17. Managing data, sharing, and privacy in ChatGPT Business — Primary Vendor Guidance; accessed 2026-10-31T23:34:14Z.
18. Cloudflare DDoS Threat Report 2026 Q3: More swarms, fewer giants — Primary Company Telemetry; accessed 2026-10-31T23:34:14Z.
19. Cloudflare’s 2025 Q3 DDoS threat report — including Aisuru, the apex of botnets — Primary Prior Baseline; accessed 2026-10-31T23:34:14Z.
20. Authorities disrupt world’s largest IoT DDoS botnets responsible for record breaking attacks targeting victims worldwide — Government Press Release; accessed 2026-10-31T23:34:14Z.
21. CRITICAL: Dysphoria Botnet Special Report — Independent Nonprofit Telemetry; accessed 2026-10-31T23:34:14Z.
22. Multi-Functional Linux Botnet “Evooo1Bot” — Independent Vendor Research; accessed 2026-10-31T23:34:14Z.
23. Understanding and Responding to Distributed Denial-Of-Service Attacks — Government Guidance; accessed 2026-10-31T23:34:14Z.
24. Upstream defences — Government Guidance; accessed 2026-10-31T23:34:14Z.