The flaw is a deserialization-of-untrusted-data vulnerability in on-premises Microsoft SharePoint. An attacker who has the required SharePoint privileges can use it to execute code on the server. That authentication requirement narrows the entry path, but it does not make the outcome modest: a compromised tenant account, stolen session, or malicious insider can turn application access into control of a server that often sits close to documents, identities, and internal workflows.

The important signal is “known exploited”

Severity scores help teams sort theoretical risk. The KEV catalog answers a different question: are attackers actually using this vulnerability? Here, the answer is yes. Once exploitation is observed, the sensible default for an exposed or business-critical server is to assume the vulnerable period may matter and to look for evidence — not merely to install the update and close the ticket.

This distinction is particularly important for SharePoint. The platform is not just another web application. It commonly connects identity, collaboration, document libraries, automation, and years of institutional memory. Code execution there can become credential theft, persistence, lateral movement, or access to material that was never intended to leave the organisation.

A practical response order

1. Find every on-premises instance. Include test farms, disaster-recovery systems, abandoned project portals, and servers that are reachable only through a VPN. Confirm product version and patch state from the host, not from an asset spreadsheet.
2. Apply Microsoft's update or mitigation. If neither can be applied promptly, isolate the service from untrusted networks. CISA's KEV guidance is explicit: remediate according to vendor instructions or discontinue use when mitigations are unavailable.
3. Preserve evidence before cleaning. Retain IIS, SharePoint, identity-provider, endpoint, firewall, and reverse-proxy telemetry. Snapshot suspicious hosts where your incident process allows it. Deleting a web shell without preserving its surrounding evidence makes scoping harder.
4. Hunt beyond the vulnerable process. Review new or modified application files, unusual child processes, scheduled tasks, services, outbound connections, privileged-account changes, and access to sensitive libraries. Correlate SharePoint activity with identity and endpoint logs.
5. Rotate what may have been exposed. If investigation finds compromise — or cannot confidently exclude it — rotate relevant service-account credentials, application secrets, certificates, tokens, and cryptographic material following Microsoft and incident-response guidance. Rotation comes after containment so fresh credentials are not immediately collected again.

Patching closes the vulnerability, not its consequences

The recurring operational mistake is treating a security update as a time machine. It prevents a fixed path from being used in the future; it does not remove accounts already created, credentials already copied, or persistence already installed. Active exploitation changes the work from vulnerability management into a combined patch-and-hunt exercise.

It also exposes a quieter weakness: credentials and recovery material tend to accumulate in collaboration platforms. Search document libraries, lists, automation configurations, and old tickets for passwords, API tokens, private keys, and environment files. Remove them, rotate them, and replace that habit with an expiring transfer mechanism. Reducing the credential inventory inside SharePoint limits the value of the next compromise, whatever its CVE number.

Sources

• NIST National Vulnerability Database — CVE-2026-58644
• Microsoft Security Response Center — CVE-2026-58644
• CISA Known Exploited Vulnerabilities catalog

The EU agency's July 2026 paper describes a security environment where offensive research, phishing, malware adaptation, and reconnaissance can be iterated at machine speed. At the same time, AI-generated vulnerability reports can flood disclosure programmes with uneven findings, and trusted software dependencies can carry attacks from the inside out. The immediate risk is not science-fiction autonomy. It is an attacker completing familiar tasks faster than an organisation can triage, approve, patch, and contain.

Four changes defenders should plan for

1. Discovery-to-exploit time keeps shrinking

Public fixes, commits, and release notes have always helped attackers reverse-engineer vulnerabilities. AI makes that comparison and adaptation cheaper. A patch released on Tuesday can become a scanning or exploitation opportunity before a conventional monthly maintenance window opens. Patch priority therefore needs live exploitability and exposure data, not only a static severity score.

2. Disclosure pipelines can become denial-of-service targets

ENISA notes that AI-generated reports initially overwhelmed parts of the vulnerability-disclosure ecosystem with mixed-quality submissions. Even as report quality improves, intake teams need automated deduplication, reproducibility checks, evidence requirements, and a fast path for findings that affect exposed systems. Otherwise the important report is buried in a syntactically convincing queue.

3. “Inside-out” supply-chain attacks get easier to scale

A trusted update, package, build action, or model dependency starts inside the boundary that perimeter controls are built to defend. AI can help an attacker study maintainers, imitate contribution patterns, adapt malicious code, and target the weakest point in a dependency graph. Provenance and build integrity become security controls, not procurement paperwork.

4. Incident response must operate in minutes and hours

Fragmented telemetry and manual hand-offs are increasingly expensive when an intrusion can change shape quickly. That does not mean handing every response decision to an autonomous agent. It means preparing bounded, reversible actions — disable a token, isolate a workload, block an indicator, preserve evidence — that automation can recommend or execute under clear human checkpoints.

What a team can change this quarter

• Patch from exposure and exploitation signals. Connect asset inventory, internet reachability, business criticality, and known exploitation to patch deadlines. Reserve emergency capacity rather than forcing every flaw through the same calendar.
• Make builds explain themselves. Pin dependencies, generate an SBOM, sign release artifacts, restrict who and what can publish, and retain provenance that links a deployed binary to reviewed source and a controlled build.
• Keep secrets out of the automation trail. CI logs, prompts, issue trackers, model context, and generated debugging output are all places where tokens can be copied. Use short-lived credentials, scoped identities, secret scanning, and expiring transfers for human hand-offs.
• Put quality gates around AI security output. Require a reproducible test case, affected-version evidence, confidence level, and human validation before an AI-generated finding triggers a destructive action or a public disclosure.
• Pre-authorise safe containment. Decide in advance who may revoke credentials, isolate hosts, block traffic, and contact suppliers. Automation is useful only when the organisation has already settled the authority and rollback path.

Speed is an architectural property

Buying an AI security product does not make a slow organisation fast. The durable advantage comes from clean telemetry, trustworthy asset ownership, rehearsed decisions, controlled software supply chains, and credentials that can be revoked without a week of coordination. Those foundations help whether the attacker uses an advanced model, a commodity scanner, or a convincing phone call.

ENISA's message is best read as a deadline for operational design: shorten the path from evidence to safe action without removing accountability. Attackers are automating their side of the workflow. Defenders need to redesign theirs.

Source

ENISA — ENISA's view on Cybersecurity in the Frontier AI Era (July 2026)

What was in there? Exactly what's in every mature ticketing system: attachments. Support tickets on the platform routinely carried documents containing clients' personal information, investment-holding details and financial data used to prepare tax filings. EY says it has no evidence of misuse so far, no extortion group has claimed the incident, and affected individuals are being offered 24 months of identity monitoring. All reasonable. But the interesting part is upstream of the response.

Ticket systems are archives wearing a workflow costume

Nobody thinks of a help-desk tool as a data warehouse. Yet consider what it optimizes for: people attach whatever's needed to resolve the issue ("here's the spreadsheet that won't import", "see the client's filing attached"), tickets are kept forever for auditability, and access is broad because support teams rotate. Multiply by years and you get a searchable, well-organized archive of the most sensitive documents in the business — maintained diligently, guarded loosely, and hosted by a vendor whose security you don't control.

This is the third act of a pattern this month's incidents keep rehearsing. The TfL attackers went through a help desk to get passwords reset. The SonicWall intrusions harvested credential stores from appliances. And now a ticketing platform gives up tax files. Different doors, same room: wherever copies of sensitive material pool by default, that's where attackers go — because one compromise yields thousands of documents nobody remembers attaching.

The third-party multiplier

The platform was a vendor's, which adds the now-familiar supply-chain twist: your data's exposure is set by the weakest SaaS tool any of your teams adopted. Vendor questionnaires won't fix that retroactively. What helps is reducing what the tool holds: if the ticket references where a document lives instead of carrying the document, a platform compromise leaks metadata, not filings.

What to do about your own ticket archive

• Audit attachments, not just access. Search your ticketing system for what's actually in it — tax documents, contracts, credentials, exported databases. Most teams are surprised.
• Set retention to match reality. A resolved ticket rarely needs its attachments after 90 days. Auto-purge attachments on closure where policy allows; keep the ticket text for audit.
• Move sensitive hand-offs out of the ticket body. When support work requires a credential or a sensitive file, pass it through a channel that expires and can be read once, and put the reference in the ticket. The workflow stays auditable; the archive stays empty.
• Treat vendor ITSM tools as data processors. Because that's what they are: scope what categories of data may enter them, and include them in your breach-notification planning — EY's timeline (access in March, letters in July) shows how long that tail is.

The uncomfortable summary: EY didn't lose a database; it lost the accumulated sediment of everyday helpfulness. Every organization has the same sediment somewhere. The fix is structural — decide that sensitive material doesn't rest in workflow tools, and give people an equally easy path that doesn't leave a copy behind.

How the chain works

wp2shell is two bugs that are individually awkward and jointly severe. The first (CVE-2026-63030) is a route-confusion flaw in the REST API's batch endpoint, /wp-json/batch/v1, which lets an unauthenticated request reach query paths that were assumed to be privileged. The second (CVE-2026-60137) is a SQL injection in the author__not_in parameter handling of WP_Query. Chained, the batch endpoint delivers the injection, and the injection escalates to code execution on the server. Affected versions run from 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1.

As of the initial disclosure there was no public proof-of-concept and no confirmed in-the-wild exploitation — but the technical details are now public, and for a target surface measured in hundreds of millions of sites, the interval between "details public" and "mass exploitation" is historically measured in days. If you run WordPress anywhere — including the forgotten marketing microsite from 2023 — verify it's on 6.9.5/7.0.2 today, and don't assume auto-update reached it: hosts with disabled auto-updates, version-pinned containers, and heavily customized installs are exactly where forced updates fail silently.

Why "in core, pre-auth" changes the math

The WordPress ecosystem's usual security story is "core is solid, plugins are the risk". That heuristic shapes real decisions — teams audit plugins and treat core as furniture. A pre-auth core RCE inverts it: every install is in scope regardless of hygiene, and attackers can scan for it generically instead of fingerprinting plugin combinations. The last flaws of this class in core are years in the past, which is precisely why patch urgency is high — muscle memory says WordPress core can wait. This one can't.

Meanwhile, at the perimeter: the SonicWall story escalated

The SMA1000 zero-days we covered this week found their operator: researchers now report the INC Ransom operation exploiting the two SonicWall flaws in tandem, gaining root on the mobile-access appliances that sit in front of corporate networks. That completes a familiar arc — zero-day, credential harvest, then ransomware crews industrializing the access. If you patched but didn't rotate the credentials and MFA seeds those boxes held, the patch closed the door after the keys left.

And the week's leak-site churn continued across regions — claims posted against a Dutch food supplier, a Hungarian building-materials maker, a UK microfinance firm and a Japanese industrial manufacturer, by groups including Play, Gunra and INC. Individually small stories; collectively the base rate that never makes headlines.

The takeaway

Two deadlines this weekend, then. Patch WordPress before the exploit writes itself — forced updates are on, but verify, don't trust. And if you own a SonicWall SMA appliance, treat it as post-compromise: patch, then rotate everything it stored, because ransomware operators demonstrably already have the playbook. Both stories reduce to the same rule that keeps recurring this month: the fix isn't finished when the software is current — it's finished when the secrets the attacker could have taken stop working.

A note on sourcing: details above come from the WordPress security release, the researchers' published analysis, and incident reporting from established security press; the INC Ransom attribution reflects current public reporting and may be refined as investigations continue.

The # that never leaves your device

A URL like example.com/s/abc123#async_Jx9… has two very different halves. Everything before the # — the path — is sent to the server with every request. Everything after it — the fragment — is not. That's not a product feature; it's how HTTP has worked since the 1990s. Fragments were designed to scroll you to a section of a page, so browsers keep them strictly client-side: they never appear in the request, in server logs, or in standard proxy logs.

That one rule makes an elegant design possible: put the decryption key in the fragment. The sender's browser generates a random AES-256-GCM key, encrypts the secret locally, uploads only the ciphertext, and appends the key to the link after the #. When the recipient opens it, their browser downloads the ciphertext, reads the key from the fragment locally, and decrypts in the page. The service in the middle stores and serves ciphertext it has no key for.

Why "one-time" is the other half of the design

A link that carries its own key is a bearer capability: whoever holds the complete URL can read the secret. That's also its weakness — links get forwarded, previewed, and logged in chat apps. The mitigation is burning the ciphertext on first read. After one successful retrieval, the server deletes what it stored; the same link opened a second time returns nothing to decrypt. A stolen link that has already been used is a dead end — and a link that arrives already-consumed tells the sender something is wrong.

Expiry completes the model: a secret that's never opened shouldn't wait around forever, so unopened ciphertext is deleted on a timer measured in minutes or days, not months.

What this model protects against — and what it can't

Against a database leak, the design holds up remarkably well: an attacker who copies the server's storage gets ciphertext without keys. Against a curious operator, likewise — there is nothing readable to be curious about. This is why the architecture is often called zero-knowledge for this mode: the knowledge genuinely isn't there.

Honesty requires the other list too. The model does not protect against someone who intercepts the complete link before the intended recipient opens it — that's why the channel you send a link through, and a short expiry, still matter. It doesn't protect against malware on either endpoint, or a recipient who copies the secret after legitimately opening it. And it requires trusting the JavaScript the service ships, since the encryption runs in the page. No honest vendor will tell you a bearer link is unconditionally safe; the claim is narrower and more useful — the server, its backups, and its operators never hold what's needed to read your secret.

Why this beats the alternatives for one-off sharing

Compare the failure modes. A password pasted in chat lives in that channel's history and backups indefinitely — this week's incident reporting is full of exactly that pattern. An email attachment is an archive entry on at least two servers. A password manager's shared vault is excellent for long-lived team credentials, but overkill and over-persistent for "here's the Wi-Fi key for the contractor". The one-time link occupies the gap: transport for a secret that should exist in transit briefly, be readable once, and leave an auditable puff of smoke instead of a copy.

The next time a tool hands you a link with a long string after the #, you'll know exactly what you're holding: the key itself, riding in the one part of the URL the internet never sees.

Here's the field guide, ranked roughly by how often each shows up.

1. Code and config: the key ring nobody meant to build

Nobody decides to store credentials in Git. It accrues: a connection string committed "just for the demo", a deploy key in a README, an .env that slipped past .gitignore. Deleting the file later doesn't help — Git history remembers, and secret scanners (both the defenders' and the attackers') read history, not just the latest commit. The fix is structural, not heroic: scanners in CI that fail the build (gitleaks, trufflehog, GitHub secret scanning), short-lived credentials that make an old leak worthless, and cloud identity federation so most keys don't need to exist at all.

2. CI/CD logs and artifacts: the echo chamber

Build pipelines are handed the most powerful credentials in the company, then asked to print debugging output. One echo, one verbose flag, one crash dump, and a token lands in a log that dozens of people and several integrations can read. Masking helps but breaks on transformations (base64, JSON-escaped, split across lines). Treat build logs as semi-public: scope CI credentials tightly, expire them in minutes via OIDC federation instead of storing long-lived secrets, and audit what your pipeline prints.

3. Chat: the archive that feels like a hallway

Chat feels ephemeral — that's the trap. Every "here's the admin password 🙏" becomes a permanently searchable record, replicated to every device and export. An attacker who lands one account doesn't read messages; they search password, apikey, -----BEGIN. The countermeasure is a habit, not a product: credentials never travel in message bodies. Send a link that expires and burns after one read, so the archive holds a dead link instead of a working key.

4. Tickets and wikis: the institutional memory problem

Support tickets, runbooks and onboarding wikis collect credentials because they're where people ask for access and write down "how to get in". Unlike chat, they're designed to be durable and broadly readable — which makes them the best-indexed credential store an intruder could ask for. Same rule as chat, plus one: when a credential must be referenced in documentation, reference where to obtain it (the vault path, the request process), never the value.

5. Inboxes: the oldest archive of all

Email is where third parties send you credentials — and where they stay, through years of forwarding rules, delegated access, and the occasional mailbox compromise. You can't always control what others send you; you can control the half-life: move received credentials into a manager immediately, delete the email, and rotate anything that arrived in plaintext, because you have no idea how many hops it took.

The common mechanics

All five share the same physics. Copies accumulate because pasting a value is easier than referencing it. Retention is unbounded because nothing in these systems expires by default. And discovery is trivial because all of them are searchable — for you and for whoever gets in. Flip each property and you get the defensive posture: fewer copies (reference, don't paste), bounded lifetimes (short-lived credentials, expiring shares), and nothing worth searching for (dead links instead of live values).

None of this requires a security team. It requires deciding that a secret at rest in a log, a thread, a ticket, or a repo is a bug — and giving people a way to share one that doesn't create a permanent copy: a channel where the secret expires, can be read exactly once, and confirms it was delivered. Make the safe path the lazy path, and the five places above stay empty.

The numbers from the case are worth sitting with. The intrusion ran from August 31 to September 3, 2024 — four days. It left 148 TfL systems inoperable, and the NCA and CPS put losses and recovery at £29 million. And it produced one of the most striking logistics operations in incident-response history: all 27,000 TfL employees were required to show up in person to have their passwords reset and identities verified, one by one.

The attack chain had no exploit in it

According to the case reporting, the pair bought partial TfL credentials on criminal forums, used them to reset the two-factor authentication on employee accounts, then impersonated an employee and talked a help-desk worker into resetting an account password. That's the entire entry chain: bought secrets, a weak reset flow, and one persuasive phone call. No zero-day, no malware innovation — the same three moves Scattered Spider has used against casinos, retailers and insurers for years.

Two people barely out of school, working from bedrooms, took 148 systems away from one of the world's largest transport authorities. The asymmetry isn't a talent story; it's a structure story. Credential-based attacks scale down to two teenagers because the defenses that stop them — phishing-resistant MFA, hardened reset procedures, credentials that can't be bought because they expire — weren't there.

Why recovery cost more than the attack

The in-person reset marathon is the detail that should stick. Once an identity system is compromised, every remote channel you'd normally use to re-issue credentials — email, SMS, the help desk itself — is potentially in the attacker's hands. TfL's answer was the only fully trustworthy channel left: physical presence, 27,000 times. That is what "re-establishing trust in credentials at scale" actually looks like when you have no pre-established secure channel for distributing new secrets.

Most organizations never budget for this. The cost of a credential compromise isn't the ransom you didn't pay — it's rebuilding the entire chain of trust afterwards, credential by credential, human by human.

What to change before it's your help desk

• Treat the help desk as your perimeter. Password and MFA resets are the highest-privilege operation in the company. Require verification that can't be socially engineered — callbacks to known numbers, manager confirmation, or in-person/video checks for privileged accounts.
• Make bought credentials worthless. The entry point was partial credentials purchased on a forum — meaning they'd leaked long before and still worked. Short-lived sessions, phishing-resistant MFA (passkeys/FIDO2, not SMS or push), and monitoring for credential-stuffing patterns turn stale loot into junk.
• Have a secure redistribution channel before you need it. The question "how do we get new credentials to thousands of people when email is untrusted?" has exactly two answers: physical presence (£29M edition), or a pre-agreed out-of-band channel where each new secret expires, can be read once, and confirms delivery. Deciding this during the incident is what makes it expensive.
• Rehearse the reset day. Tabletop the scenario where your identity provider itself is suspect. Who re-issues what, over which channel, verified how? TfL improvised it under pressure with the whole city watching.

The takeaway

The sentencing closes the legal chapter, but the economics are the lesson: the attackers spent close to nothing, and the defenders spent £29 million — most of it on the unglamorous work of making 27,000 identities trustworthy again. Every credential that leaks and keeps working, every reset flow that trusts a voice on the phone, is a prepayment on that bill. Credentials should expire, resets should be hard to fake, and the channel for handing someone a new secret should exist before the morning you need 27,000 of them.

SonicWall: the appliance as a secrets vault — for the attacker

SonicWall warned that two SMA1000 vulnerabilities are being exploited in tandem as zero-days: CVE-2026-15409, an unauthenticated server-side request forgery in the Work Place interface rated CVSS 10.0, and CVE-2026-15410, a post-authentication command injection in the management console. Affected models include the SMA6210, SMA7210 and SMA8200v; the US government gave federal agencies until July 17 to patch or unplug.

The payload is the part that deserves a second read. Per incident responders, the attackers used the chain for stealthy initial access and then extracted credentials, active session databases, and TOTP seed configurations. Read that last one again: the seeds that generate your six-digit MFA codes. Whoever holds the seed can mint valid codes forever — your second factor stops being a factor. It's a reminder that MFA seeds, session stores and cached credentials are secrets like any other, and the appliances that hold them are single points where thousands of them can be stolen at once.

The rest of the fire drill

• Zoom Workplace for Windows (CVE-2026-53412, CVSS 9.8) — a critical flaw that could enable account takeover; updates are out. Collaboration tools sit on every machine in the company, which makes them perimeter whether you think of them that way or not.
• Microsoft Patch Tuesday — a record ~570 vulnerabilities addressed in one cycle, including two zero-days already exploited in attacks and one publicly disclosed. Patch pipelines built for a few dozen fixes a month are being stress-tested by volume alone.
• SharePoint, again — CISA warned that three vulnerabilities in internet-exposed on-premises SharePoint servers are under active exploitation. If last year's ToolShell wave didn't move your on-prem SharePoint behind a VPN or into retirement, this is the second memo.
• Also this week: US military health beneficiaries' data was exposed in a breach at TRICARE West, and Spanish police disrupted a fraud ring accused of laundering €140 million from cyberattacks — a useful reminder that the money side of this economy is industrial too.

The pattern: secrets concentrate at the edge

The SonicWall incident is the cleanest illustration in months of a truth that patch notes tend to bury: edge appliances aren't just doors, they're warehouses. VPN concentrators and secure-access gateways hold password caches, live sessions, and MFA material for the whole workforce. Compromise one and you don't need to phish anyone — you walk out with the identity layer itself. The same logic applies to anywhere else secrets pool: chat exports, ticketing systems, CI logs, inboxes.

What actually helps

• Patch the named boxes now — SMA1000 (both CVEs), Zoom for Windows, exposed SharePoint. The federal deadline for SonicWall was this week for a reason: exploitation is current, not theoretical.
• After patching, assume extraction. If an exploited appliance held credentials, sessions or TOTP seeds, rotate them — re-enroll MFA where seeds may have left. A patched box with stolen seeds is still a compromised identity system.
• Prefer phishing-resistant, device-bound factors. Passkeys and hardware keys don't have a seed file an appliance can leak. TOTP was a huge upgrade over passwords; it still depends on a shared secret sitting in storage somewhere.
• Keep secrets moving, not resting. Every archive of credentials — in an appliance, an inbox, a chat history — is a future headline waiting for its CVE. Share secrets over channels that expire and self-destruct, keep the durable copies in a proper manager, and let everything in between be short-lived.

A note on sourcing: the incidents above were reported this week by the vendors themselves, national agencies, and established security press. Details of the SonicWall intrusions come from public incident-response reporting and may evolve as investigations continue.

A note on sourcing: every incident below was reported by reputable outlets, vendors, or government bodies during the week. Where a claim comes from an attacker's leak site and hasn't been independently verified, we say so.

Romania and the EU: Turla, named and condemned

On July 14, Romania formally condemned hostile cyber operations attributed to groups controlled by Russia's FSB — specifically the long-running espionage actor Turla, active since at least 2004. President Nicușor Dan called the attacks part of "a broader hybrid campaign, meant to undermine the stability of our democracies." Reported targets include government institutions and critical infrastructure; earlier this year, dozens of Romanian military email addresses were compromised, though classified systems were reportedly not reached.

Romania wasn't alone. France reported Russian cyber campaigns affecting roughly ten European countries, the EU's High Representative issued a formal condemnation of Russia's "malicious cyber ecosystem," NATO's North Atlantic Council published its own statement, and Germany and France summoned Russian ambassadors. Espionage against EU institutions is not new — what's notable is how publicly and collectively it was attributed this time.

European tech: D1R goes big-game hunting

A newly tracked ransomware operation calling itself D1R updated its leak site on July 13 with three high-profile names at once: chip designer Arm (UK), engineering giant Bosch (Germany), and design-software maker Synopsys (US). Researchers link the campaign to exploitation of perimeter appliances — a Check Point Security Gateway flaw (CVE-2026-50751) used to bypass VPN authentication, and a Cisco Secure Firewall FMC bug (CVE-2026-20131) used to pivot deeper.

Important caveat: these are attacker claims. Synopsys says it has found no evidence of a breach, and the scale of what was actually taken from any of the three is unverified. But the target selection — semiconductor IP and the software that designs it — says a lot about where extortion economics are heading, and the entry vector is the same story security teams have lived through for three years: the VPN box at the perimeter.

United States: Accenture's 35 GB problem

A threat actor using the handle "888" claimed on a cybercrime forum to have taken roughly 35 GB from Accenture — not customer records, but source code, RSA and SSH keys, Azure personal access tokens, Azure Storage keys, and configuration files, with a screenshot of a private Azure DevOps repository as proof. Accenture said it was "aware of this isolated matter" and had "remediated its source," without confirming what, if anything, left. We wrote a separate deep-dive on why a leak of this shape — keys inside code — is its own category of incident.

Elsewhere in the US: the Conduent healthcare breach grew to more than 62 million affected individuals in updated filings; AssuranceAmerica disclosed nearly 7 million records exposed after a single employee account was compromised; and reporting pointed to a compromise of DHS information-sharing infrastructure. On July 14 the US Treasury sanctioned a VPN provider and two individuals accused of servicing ransomware crews — infrastructure takedowns are increasingly financial, not just technical.

Asia: Japan's telecom breach of the year

Japanese telecom giant KDDI confirmed that attackers accessed the email platform serving five ISPs (including BIGLOBE, NIFTY and JCOM), exposing about 12.2 million email addresses and 7.6 million passwords. The intrusion began on May 16 through a zero-day in a third-party email platform — unknown even to the vendor — and wasn't detected until June 17. Passwords at that scale become credential-stuffing ammunition against every other service where people reused them, which is why the disclosure was paired with a forced reset campaign.

The wider region had a busy week too: ransomware claims were posted against Saudi jewelry manufacturer L'azurde, Hong Kong's Intron Technology, and India's Omax Autos, among others — all leak-site claims at this stage, but a reminder that extortion is fully global.

Also worth your attention

• Developer tools as attack surface: researchers disclosed a zero-click remote-code-execution chain in the Cursor AI code editor, and active attacks abusing an Azure CLI weakness to sidestep MFA and Conditional Access. The tools that hold your credentials are targets themselves.
• AI-operated ransomware: reporting this week described what researchers called the first ransomware intrusion conducted almost entirely by an autonomous AI agent, exploiting a Langflow vulnerability. Whatever the label ends up being, the marginal cost of running an intrusion is falling fast.

The common thread

Strip the names away and the week reduces to three root causes: perimeter appliances with known flaws (D1R's entry path), a zero-day in a trusted third-party platform (KDDI), and long-lived credentials sitting where they could be copied (Accenture's alleged keys-in-code, KDDI's password trove). Nobody broke encryption. They found secrets that were reusable and reused them.

The practical lesson is the same one every week like this teaches: a credential is dangerous in proportion to how long it stays valid and how many places it lives. Prefer short-lived, single-purpose secrets. Rotate what might be exposed. And when you have to hand someone a password or a key, use a channel that expires and self-destructs — not an inbox or a chat log that quietly becomes an archive of everything you ever shared.

Fairness first: attacker claims are marketing, and until someone independently validates that archive, the numbers deserve skepticism. But the shape of the claim is worth studying regardless of how this particular story resolves, because it describes the most common failure mode in modern engineering organizations: repositories quietly become key rings.

A code leak is a credential leak

Ask what each claimed artifact type actually unlocks and the incident stops looking like intellectual-property theft and starts looking like an access package:

• SSH keys — direct authentication to servers, jump hosts, and Git remotes. A passphrase-less key in a repo is a door that opens for whoever holds the file.
• Azure personal access tokens — scoped like the developer who minted them: repos, pipelines, artifact feeds. PATs are long-lived by default and rarely inventoried.
• Storage access keys — full read/write on storage accounts, independent of any user identity, invisible to conditional-access rules.
• Configuration files — connection strings, service passwords, webhook URLs, internal hostnames: a map of the estate plus some of the keys to it.

That's why "source code stolen" is the wrong headline for incidents like this. Code can be rewritten; the credentials embedded in and around it keep working until someone finds and revokes every copy. The half-life of a leaked repository is measured in the lifetime of the longest-lived secret inside it.

Why this keeps happening to sophisticated companies

Nobody decides to store keys in Git. It accumulates: a config committed "just for the demo," a deploy key pasted into a README, a token in a CI variable that gets echoed into a build log, a .env that slipped past the .gitignore. Each one is small; a decade of them across thousands of repositories is 35 GB with keys in it. Accenture — a company that sells security consulting — has now had several public incidents since 2017. If it can happen there, the honest conclusion is that it happens everywhere, and the differentiator is how fast you can find and kill exposed credentials, not whether they exist.

The playbook if this were your repo

Treat a repository exposure as a credential incident from minute one:

• Assume everything in the repo is burned. Rotate first, and investigate afterwards. Waiting to "confirm exfiltration" before rotating is how a leak becomes a takeover.
• Inventory before you need it. Run secret scanners (gitleaks, trufflehog, GitHub secret scanning) across the full history, not just HEAD — deleting a key from the latest commit doesn't remove it from git log.
• Shorten lifetimes structurally. Replace long-lived PATs and static storage keys with short-lived, identity-bound credentials (OIDC federation for CI, managed identities, SAS tokens with expiry). A key that expires in an hour is a much smaller story than one minted in 2023.
• Fix the rotation channel too. The moment you rotate, the new secret has to reach a teammate or a deployment — and the reflex is to paste it into chat or email, recreating the original problem in a new location. Rotated credentials should travel through a channel that expires, can only be read once, and leaves an audit trail.
• Watch for reuse. Exposed keys get tried. Alert on authentication from new networks with old credentials, and on PAT/API usage patterns that don't match the owning team.

The quiet takeaway

Whether "888" has 35 GB or 35 MB, the claim worked as an advertisement because everyone who read it recognized their own repositories in it. The fix isn't a heroic cleanup sprint once a headline lands — it's making long-lived, copyable secrets structurally rare: short lifetimes by default, scanning in CI, and sharing channels that self-destruct instead of becoming archives. Secrets should be boring, brief, and single-use. The ones that make headlines are always the ones that were allowed to live forever.

A note on sourcing: every incident below was widely reported by reputable outlets, vendors, or government bodies. Where attribution or scale was contested, we say so rather than pretend to certainty.

Nation-state espionage went mainstream

Salt Typhoon was the defining espionage story of the era. A China state-linked group breached at least nine major US telecom carriers, reaching the lawful-intercept (wiretap) systems and call metadata that carriers are required to maintain; the FBI later described 200+ targets across 80+ countries. The US Treasury sanctioned a linked firm in January 2025. It's widely called one of the worst telecom compromises in US history — and a reminder that the surveillance infrastructure built for law enforcement is itself a target.

SharePoint "ToolShell" (CVE-2025-53770) saw an unauthenticated remote-code-execution chain in on-premises Microsoft SharePoint mass-exploited worldwide from July 2025, compromising 150+ organizations across four continents, with some intrusions escalating to ransomware. Microsoft attributed activity to China-linked groups (Linen Typhoon, Violet Typhoon) alongside a ransomware actor.

The edge kept bleeding, too. Ivanti Connect Secure (CVE-2025-0282) and a pair of Cisco ASA/FTD zero-days (CVE-2025-20333 and CVE-2025-20362) were exploited in the wild to plant espionage malware and persistence that survived reboots. The pattern is now familiar: VPNs, firewalls, and other internet-facing appliances are prime real estate for suspected nation-state actors, because they sit at the perimeter and are hard to inspect.

The supply chain was the real target

The Salesloft Drift breach (UNC6395) was the landmark identity/SaaS supply-chain attack. In August 2025, attackers stole OAuth refresh tokens from the Salesloft "Drift" chatbot integration and used them to bulk-export Salesforce data from 700+ organizations — including Cloudflare, Google, Palo Alto Networks, and Zscaler — then mined the stolen records for cloud keys and other secrets. No password was cracked; a trusted integration's tokens were simply reused. It's the clearest case yet that in a connected SaaS world, an OAuth token is a skeleton key.

The npm "Shai-Hulud" worm hit open source. After a maintainer was phished via a fake 2FA-reset domain, attackers hijacked widely used packages (including debug and chalk, with billions of weekly downloads combined) and planted a self-replicating worm that steals cloud and CI tokens and spreads to other maintainer accounts. A later wave reached tens of thousands of GitHub repositories. One phished developer, and the blast radius was the entire JavaScript ecosystem.

Extortion hit record scale

The Oracle E-Business Suite zero-day (CVE-2025-61882) was the marquee CVE-driven event. The Cl0p extortion group exploited an unauthenticated RCE (CVSS 9.8) to steal data from dozens of enterprises, then ran a mass executive-email extortion campaign before Oracle patched it in October 2025 — a textbook example of a single flaw turned into an assembly line of extortion.

The Marks & Spencer attack brought it to the high street. In April–May 2025, social engineering of an IT help desk led to DragonForce ransomware and data theft across major UK retailers (M&S, Co-op, Harrods), disrupting M&S online operations for weeks with an estimated combined impact in the hundreds of millions of pounds. It was attributed to the English-speaking crew "Scattered Spider"; several suspects were arrested by the UK's National Crime Agency in July 2025. The entry point wasn't a zero-day — it was a persuasive phone call.

When the data itself is the crown jewel

A run of breaches showed how much sensitive data sits with third parties and back-office providers:

• Conduent — a ransomware intrusion at the business-process giant reportedly stole around 8.5 TB of data; the affected population grew across disclosures into the tens of millions, placing it among the largest US breaches on record. Claimed by the SafePay group.
• DaVita — a ransomware attack on the kidney-dialysis provider exposed protected health information of roughly 2.7 million people (April 2025), attributed to the Interlock group, which also forced a state-of-emergency declaration after hitting the City of St. Paul, Minnesota.
• Qantas — attackers compromised a third-party customer-servicing platform via a call center (June 2025), exposing data of up to ~5.7 million customers, amid an FBI warning that Scattered Spider was targeting aviation.
• Carnival — a 2026 social-engineering intrusion exposed data of roughly 6 million individuals, including passport and driver's-license numbers; claimed by the ShinyHunters extortion brand, per reporting.

Destruction, not just theft

Two incidents were about damage rather than data. Jaguar Land Rover was forced to halt global production for roughly five weeks from late August 2025, paralysing its supply chain with an estimated impact near £1.9B — described as possibly the most economically damaging cyberattack in UK history, prompting a government-backed loan guarantee. (Attribution was claimed by actors linked to the Scattered Spider/Lapsus$ scene but remains debated.) And in March 2026, destructive malware wiped tens of thousands of devices at the US medical-device maker Stryker — reportedly with staff watching machines wiped in real time — in a rare destructive attack on a Western manufacturer, reported as the work of an Iran-aligned hacktivist group.

The common thread

Look across the list and the same few root causes keep appearing: stolen tokens and credentials (Salesloft, npm, Salt Typhoon's harvested access), social engineering of a human (M&S, Qantas, Carnival), and trust placed in a third party that got compromised (Conduent, Drift, the supply-chain worms). Very little of it required breaking encryption. It required finding a secret that was lying around — an OAuth token, a saved password, an API key in a support ticket — and using it.

That's the uncomfortable lesson for everyone, not just the Fortune 500: secrets are dangerous in proportion to how long they sit somewhere reusable. The defensive moves that actually move the needle are unglamorous — phishing- resistant MFA, short-lived tokens, least privilege, and not leaving credentials in inboxes, chat logs, and ticketing systems where a single compromise turns into an archive. If you're going to hand someone a credential, hand them something that expires and can't be replayed, not a message that lives forever. Most of the year's biggest headlines started with a secret that outlived its usefulness.

Teams: one Business plan, up to five people

If you're on the Business plan, you can now bring your team along without buying separate subscriptions for everyone. From your profile you generate a single-use invite link, valid for seven days, and send it however you like. When a teammate opens it and joins, their account is lifted to your Business tier automatically — files, API access, longer audit retention, all of it.

The invite links carry their token in the URL fragment, which browsers never send to a server, and each link works exactly once. You can see who used which invite, revoke unused ones, and remove members at any time, up to five seats. No email system is involved — you copy the link and share it over whatever channel you already trust.

Annual plans: two months free

Every paid tier now has a yearly option priced at ten months instead of twelve — so an annual plan is effectively two months free versus paying monthly. On the upgrade page you'll find a Monthly / Annual toggle; pick whichever fits how you'd rather budget. Nothing else changes: same features, same limits, just a lower effective rate for committing to a year.

Self-serve checkout: no more "contact us"

Previously, moving from the free trial to a paid plan meant emailing us and waiting. That's gone. The upgrade button now takes you straight to a secure hosted checkout, and your plan activates the moment payment clears. If you're already subscribed, the same buttons route you to a billing portal to switch plans, update your card, or cancel — and there's a hard guard against ever being charged twice.

Payments are handled by Stripe as merchant of record, so on your statement the charge appears via Link and your receipts and invoices are emailed to you automatically. You can download past invoices as PDFs from your profile at any time.

A note on the free trial

New accounts still start with a 14-day trial with full access and no card required. When the trial ends, your account and any secrets you've received stay intact — you just choose a plan to keep creating new ones. Nothing is auto-charged, because we never took a card to begin with.

As always, none of this changes the core guarantee: secrets are encrypted in your browser, and our servers never receive plaintext or decryption keys. The billing system knows what plan you're on — never what you shared.

Step one is always search

Chat and email are, functionally, searchable databases of everything your team has ever said. That's what makes them useful — and what makes them a goldmine after a compromise. The standard opening moves are boringly effective: search for password, api key, secret, token, .pem, AKIA (the prefix of AWS access keys), BEGIN PRIVATE KEY, or the name of your cloud provider. Whatever your team pasted, the search box finds.

Automated tools do the same at scale. Secret-scanning engines that defenders use to catch leaks in code work just as well for an attacker sifting an exported mailbox — regex patterns for key formats, high-entropy strings, and known token shapes turn a dump into a tidy list of live credentials.

Why "we use TLS" doesn't help here

Transport encryption protects the message while it travels. It does nothing about the message sitting in the recipient's inbox, your sent folder, both providers' servers, every backup, and every device either party has signed into since. A password sent in 2023 is present in all of those places today. Compromise any one of them and the credential is exposed — years after you stopped thinking about it.

The offboarding problem

There's a quieter version of this that doesn't even require a breach. The contractor you stopped working with two years ago still has every credential you ever sent them, scattered across their inbox and chat history. You have no inventory of what they hold and no way to revoke a copy that lives in someone else's archive. The exposure didn't end when the engagement did.

Removing secrets from the archive

The fix isn't a better password or a stern policy — it's making sure the secret was never in the searchable archive to begin with. That means sending a one-time link instead of the credential itself. The secret is encrypted in your browser; the decryption key rides in the URL fragment, which never reaches any server; and the first open destroys it. What lands in Slack or email is a link that, once used, opens nothing. The channel's retention problem stops mattering, because there's nothing sensitive left to find.

Two habits make this robust:

• Treat a dead-on-arrival link as an incident. One-time delivery doubles as a tripwire — if a link reports "already viewed" before your recipient opened it, someone else did. Rotate the credential; you just caught an interception that a plain email would have hidden.
• Invert the flow when you're receiving. Ask for secrets via a request link rather than letting people reply with a password in plaintext. It encrypts in their browser and gives you a one-time read — so the secret never lands in your inbox either.

Credential leaks are rarely exotic. They're an old message, found later, by the wrong person. The remedy costs thirty seconds: share something that dies on arrival instead of something that lives in the archive forever.

What actually shipped

In August 2024, NIST finalized the first post-quantum standards, with FIPS 203 (ML-KEM) as the key-encapsulation mechanism — the part that protects how two parties agree on a session key. That's the piece that matters most, because the key exchange is exactly what a future quantum computer would target.

Deployment followed fast. Major browsers rolled out hybrid post-quantum key exchange for TLS, so a growing share of everyday HTTPS connections are already protected by a classical-plus-ML-KEM combination. Signal and Apple's iMessage both moved to post-quantum key establishment for messaging. The through-line: the industry converged on hybrid designs — running the classical algorithm and the post-quantum one together — rather than betting everything on the newer scheme.

Why hybrid, not replacement

Lattice-based cryptography like ML-KEM is younger than elliptic curves, and prudent engineering doesn't throw out the battle-tested thing to adopt the new thing wholesale. Hybrid key agreement runs both and combines their outputs through a key-derivation function, so an attacker has to break both the classical and the post-quantum layer. If ML-KEM is someday weakened by cryptanalysis, you still have today's security; if a quantum computer arrives, the lattice half holds.

The reason you can't wait for the timeline

Estimates for a cryptographically relevant quantum computer range from a decade to never — and arguing the date misses the point. The useful frame is Mosca's inequality: if the time your data must stay secret, plus the time it takes you to migrate, is longer than the time until the machine exists, you're already late. This is what makes harvest now, decrypt later a present-tense threat: an adversary can record encrypted traffic today and simply wait. A password you'll rotate next week doesn't care. An SSH key, a database export, medical records, M&A documents — anything with a secrecy lifetime measured in years — very much does.

Where Secretus fits

Maximum Security mode adds ML-KEM-768 hybrid post-quantum key agreement to its authenticated, X3DH-style browser-to-browser handshake, combining the classical and post-quantum outputs before the per-message ratchet takes over. It's aimed squarely at harvest-now-decrypt-later risk for the secrets that outlive a news cycle. And because that mode sends the secret directly between browsers over WebRTC, there's no stored ciphertext sitting on a server to be harvested in the first place.

The migration most people were planning to do "when quantum computers are real" already happened in the tools they use every day. For long-lived secrets, matching that posture now — not later — is the whole point.

In 1979, Adi Shamir (the "S" in RSA) published a two-page paper that solves this exactly: split the secret into n shares so that any k of them reconstruct it, while k − 1 shares reveal nothing at all. Not "nothing practical" — mathematically, provably nothing.

The intuition: points on a curve

Two points define a line. Three points define a parabola. In general, you need k points to pin down a polynomial of degree k − 1.

Shamir's trick: hide the secret as the y-intercept of a random polynomial. Want a 3-of-5 split? Pick a random degree-2 polynomial whose value at x = 0 is your secret, then hand out five points on the curve — one per person. Any three holders can redraw the parabola and read the intercept. Two holders? There are infinitely many parabolas through their two points, one for every possible secret value, all equally likely. Their shares are literally worthless — which is the entire point.

This is what cryptographers call information-theoretic security: the guarantee doesn't depend on a computational problem being hard. A quantum computer the size of Jupiter cannot extract a secret from k − 1 shares, because the information simply isn't in them.

From parabolas to bytes

Real implementations don't draw curves over ordinary numbers — rounding would leak information. They work in a finite field, typically GF(256), which conveniently has exactly one element per possible byte value. Each byte of your secret gets its own polynomial; each share ends up the same size as the secret. The arithmetic is exact, fast, and runs comfortably in a browser.

Choosing k and n in practice

• 2-of-3 — the founder setup. You, your co-founder, and a sealed share in a safe. Either of you plus the safe recovers it; a single stolen laptop doesn't.
• 3-of-5 — the classic ops-team split. Any three engineers can rotate the master credential at 3 a.m.; no pair can collude quietly, and two people can be on holiday without blocking an incident.
• 4-of-7 — board-level or DAO-style control for keys that move money or sign releases.

The two failure modes to balance: set k too high and you've built a denial-of-service against yourself (shares get lost; people leave); too low and collusion gets cheap. A useful rule of thumb is k = ⌈n/2⌉ + 1.

What Shamir doesn't solve

Honesty requires the fine print. Plain Shamir assumes shares are delivered securely (splitting a secret and then emailing the shares defeats the purpose), assumes holders return correct shares at reconstruction (verifiable secret sharing extends the scheme if you need that), and says nothing about the moment of reconstruction itself — wherever the secret is reassembled becomes, briefly, the thing you were trying to avoid: a single point holding the whole secret.

How Secretus uses it

Team Split in Secretus runs Shamir over GF(256) entirely in your browser — the splitting, and later the reconstruction, never touch our servers. Each holder receives their share inside a link's URL fragment, which browsers never transmit to any server, so delivery doesn't leak shares either. Reconstruction happens client-side when k holders contribute their shares, and optional expiry (24 hours to 30 days) bounds the exposure window. No single teammate, no single channel, and certainly not us, ever holds enough to read the secret.

Shamir's paper was titled "How to share a secret". Forty-seven years later, it's still the correct answer.

"Harvest now, decrypt later" (HNDL) is exactly what it sounds like. An adversary with network visibility — an ISP tap, a compromised exchange, a state actor on a backbone — stores encrypted sessions today, betting that a cryptographically relevant quantum computer will eventually run Shor's algorithm and unwrap the key exchange retroactively. The encryption isn't broken today. It doesn't need to be. Storage is cheap, and patience is free.

Why the key exchange is the weak point

Modern encrypted channels (TLS, Signal, WebRTC's DTLS) typically protect data with symmetric ciphers like AES-256 — which quantum computers barely dent. The vulnerable part is how the two sides agreed on the key: elliptic-curve Diffie-Hellman. Shor's algorithm, on a large enough quantum computer, solves the discrete-log problem ECDH rests on. Recover the key exchange, and the AES key — and everything it protected — falls out for free.

Does the timeline matter? Wrong question

Estimates for a cryptographically relevant quantum computer range from a decade to never, and arguing about the date misses the point. The right question is Michele Mosca's inequality: if the time your data must stay secret, plus the time it takes you to migrate, exceeds the time until the machine exists — you are already late. A password you'll rotate Tuesday doesn't care. An SSH key to infrastructure that will run for years, a database dump with customer PII, M&A documents, medical records — these have secrecy lifetimes measured in decades. For them, HNDL is not a future threat; the harvesting is the attack, and it can only happen now.

What NIST standardised

In August 2024, NIST finalised FIPS 203: ML-KEM (Module-Lattice Key-Encapsulation Mechanism, formerly CRYSTALS-Kyber). Its security rests on lattice problems — specifically Module-LWE — for which no efficient quantum algorithm is known. ML-KEM-768, the middle parameter set, targets security comparable to AES-192 and is what most of the industry (browsers, Signal, iMessage) has converged on.

Hybrid: the engineering-honest approach

Lattice cryptography is newer than elliptic curves, and prudent engineering doesn't bet everything on the new thing. The emerging consensus is hybrid key agreement: run classical ECDH and an ML-KEM encapsulation, then feed both outputs through a key-derivation function. An attacker must break both — the elliptic curve and the lattice problem — to recover the session key. If ML-KEM someday falls to clever cryptanalysis, you still have today's ECDH security; if quantum computers arrive, the lattice half holds.

What Secretus does

In Maximum Security mode, the X3DH-style authenticated handshake between the two browsers is hybridised with ML-KEM-768: the classical ECDH shared secrets and the post-quantum encapsulation are combined through HKDF-SHA-256 into the session key, before the browser-side symmetric ratchet derives per-message keys. The secret itself travels directly browser-to-browser over WebRTC — so there's no stored ciphertext to harvest from a server at all, and what an on-path adversary can record is protected against both today's and tomorrow's cryptanalysis.

You can't retroactively protect traffic you sent unprotected. That's the uncomfortable asymmetry of HNDL — and the reason "we'll migrate when quantum computers are real" is a plan to be exactly one harvest too late.

Both fail the same way, for the same reason: retention.

The problem isn't interception — it's storage

TLS protects messages in transit; almost nobody is sniffing your packets. The real exposure is that email and chat are databases of everything ever sent. The password you emailed in 2023 is still there — in the recipient's inbox, your sent folder, both providers' servers, every backup, and every device either of you has logged into since. When any one of those is compromised — one successful phish, one stolen laptop, one reused password on the client's side — the attacker doesn't get one credential. They get the archive. "Search inbox for password" is a standard post-breach move precisely because it works.

Add the offboarding problem: the contractor you stopped working with two years ago still has every credential you ever Slacked them, and you have no way to know which ones, let alone revoke the copies.

What "good" looks like

A credential handoff is safe when it has these properties:

• Ephemeral — the message ceases to exist after delivery, automatically, without relying on anyone's discipline.
• End-to-end encrypted — no server in the middle can read it, so a breach of the middleman reveals nothing.
• Delivery-confirmed — you know it arrived, and to whom, because exactly one open is possible.
• Accountless for the other side — clients won't install a tool or create an account for a 30-second task. Any workflow that requires it will be bypassed back to email.

The workflow that survives contact with real clients

1. Send a one-time encrypted link. The credential is encrypted in your browser; the decryption key rides in the URL fragment, which never reaches any server. The first open destroys the secret — if the link leaks afterwards, it opens nothing.
2. Send the link over the channel you already share (email, Slack, WhatsApp). This is now safe: the channel only ever saw a link that no longer works. Its retention problem stops mattering.
3. If the link arrives already-dead, treat it as an incident. One-time delivery doubles as a tripwire: "already viewed" before your client opened it means someone else did. Rotate the credential — you just caught an interception that email would have hidden forever.
4. For the crown jewels, skip storage entirely. Live P2P transfer moves the secret directly between your browser and the client's, end-to-end encrypted with forward secrecy — it never exists on any server, even as ciphertext.
5. Receiving credentials? Send a request link instead. Clients will otherwise reply with the password in plaintext — it's what people do. A secret-request link inverts the flow: they paste, it encrypts in their browser, you get a one-time read.

The checklist

• Never send credentials as message text — only as one-time links.
• Set the shortest expiry the workflow tolerates (hours, not weeks).
• Rotate immediately if a link reports "already viewed".
• Use P2P mode for keys with long lifetimes (SSH, signing, cloud root).
• Request secrets via request links; never let clients improvise.
• Keep an audit trail of what was shared when — without storing the secrets themselves.

The uncomfortable truth about credential leaks is that they're rarely exotic. They're an old email, found later, by the wrong person. The fix costs thirty seconds: share a link that dies on arrival, instead of a message that lives forever.