Bitget's signing process authorised a forgery, Salesforce said blocked after the data left, a rogue MFA provider survives your reset, Google can't prove compliance, and ISO 9001 audits culture.
In this edition
- 01Bitget's signing process worked perfectly. It signed a forgery.
- 02A rogue MFA provider steals the password, then survives the reset.
- 03The agent said the data was blocked. It had already been sent.
- 04Google fined 403 million euros, partly for not being able to prove compliance.
- 05ISO 9001:2026 makes quality culture auditable. You can't write a procedure for that.
Get the next GRC Brief in your inbox.
Subscribe to The GRC BriefBitget's signing process worked perfectly. It signed a forgery.
On 24 September the crypto exchange Bitget detected 19 unauthorised transfers out of its hot and warm wallets, roughly 351.6 million dollars in ether, XRP and stablecoins across seven chains. Cold wallets were untouched. The mechanism is the part that should interest you. According to the exchange's own security team, the attackers breached a critical backend wallet system, used it to spoof the transfer details, and then triggered Bitget's normal authorised signing process to move the funds. Chief executive Gracy Chen said private key compromise has been ruled out. So nothing cryptographic broke. The signing control did exactly what it exists to do, on instructions it had no way to question. How the attackers got in remains under investigation. Bitget points to VPN infrastructure previously linked to North Korean activity, though that attribution is preliminary and other analysts dispute it. Withdrawals are suspended, and a 464 million dollar protection fund covers the loss.
Source: CNBC · Bitget breach, 25 Sep 2026
My take
Read past the crypto, because the shape of this exists in your organisation. It is an authorisation failure. The signing control protected the key, not the truth of the instruction: it was asked to authorise a transfer, it confirmed it was allowed to authorise transfers, and it signed. Nobody verified that the transfer was real. Swap wallet for payment run, or for supplier bank details, and you have business email compromise with better cryptography.
The control you actually need sits upstream, on the integrity of what reaches the signer. Where did this instruction originate, does it match an approved source, and is the system that composes transfers trusted more carefully than the one that signs them. And hold the North Korea line lightly for now: it's preliminary, the entry point is unknown, and Lazarus has become a label for anything vaguely DPRK-shaped. The mechanism is the lesson, not the flag.
A rogue MFA provider steals the password, then survives the reset.
Varonis Threat Labs published TrustSink, an abuse of the external authentication model demonstrated against Microsoft Entra. Entra lets you delegate the second factor to an external MFA provider: the user enters their password, Entra redirects, and if the provider returns a valid signed token the MFA requirement is treated as satisfied. An attacker who already holds a privileged Entra account can register a rogue provider, which then shows a convincing copy of the Microsoft password page at the exact moment the user is expecting a second step. The password goes to the attacker in plaintext, the provider returns a valid signed token, and the login completes with no error. In the test tenant every sign-in looked normal while the researchers' server collected passwords, timestamped, with source IPs. Resetting the password does not remove the provider. It stays in the flow and captures the replacement.
Source: BleepingComputer · Varonis Threat Labs, 22 Sep 2026
My take
Second time in two months that the same lesson has landed: a password reset does not evict an attacker. In August it was a phishing kit enrolling its own passkey, which survived the reset. Here the rogue provider survives the reset and harvests the replacement. So the order of operations is now a control in its own right. Remove the persistence first, the provider, its applications, keys and redirect URIs, and rotate credentials second. The other way round, you have handed over the new password.
Be precise about what this is, because it matters. It's post-compromise, not initial access: registering a rogue provider needs Global Administrator or Authentication Policy Administrator. So the finding upstream is standing privilege, not broken MFA. And notice what Entra verified. A valid signature on a token claiming the second factor happened. Never that it happened.
The agent said the data was blocked. It had already been sent.
Zenity Labs found three flaws in Salesforce Agentforce, together named SalesBleed. The way in is Web-to-Lead, Salesforce's own public lead-collection form, which feeds straight into the CRM. Malicious instructions submitted through that form sit dormant until an employee asks an Agentforce agent to work on the lead, at which point the agent reads and acts on them. Two of the flaws allowed zero-click exfiltration of leads and accounts data using HTML image tags, defeating Trusted URLs, the mechanism meant to stop the agent reaching unapproved domains, which failed to recognise top-level domains. Zenity reports that Agentforce told the user the content had been blocked by the organisation's security policies while the CRM data was already sitting on the attacker's server. The third flaw let the agent post phishing into internal Slack channels under its own identity. Reported on 1 June, fixed by 19 August.
Source: SecurityWeek · Zenity Labs, 25 Sep 2026
My take
Pin that one sentence to the wall. The security mechanism displayed a policy block after the data had gone. You got the reassuring message and the breach, from the same control, in the same second. If you ever needed proof that a control reporting success is not the same as a control working, it arrived this week with a screenshot.
Two things to take into your own environment. First, a public lead form is untrusted input with a direct path to your crown jewels, so ask what can write into anything your agents read. Second, the agent had no idea who was driving it, so it signed the phishing with its own trusted name. That is the concrete version of advice I gave a fortnight ago: one identity per agent, and logs of what the agent actually did rather than what it was meant to do.
Google fined 403 million euros, partly for not being able to prove compliance.
On 21 September the Irish Data Protection Commission fined Google Ireland 403 million euros and ordered it to bring its processing into compliance within six months. The inquiry, opened in February 2020 after complaints from European consumer organisations, examined location data in three features, Web and App Activity, Location History and Location Accuracy, between May 2018 and February 2020. The findings: unlawful and unfair processing in two of them, a failure of transparency across all three, retention of location data beyond what was necessary, and, for Location Accuracy, a failure to demonstrate compliance with lawfulness, fairness and transparency. Deputy Commissioner Graham Doyle said location data can reveal inherently private information, that people may have been unaware it was used to target them with advertising or infer their interests, and that the retention aggravated that loss of control.
Source: Data Protection Commission · DPC decision, 21 Sep 2026
My take
Look at the grounds. No breach, no hack, no clever attack. Lawfulness, fairness, transparency, retention, and an inability to demonstrate compliance. That last one is Article 5(2), and it's the same thread as everything above: being compliant and being able to evidence it are not optional halves. If you cannot show your working, the regulator treats it as not done. Retention was named as an aggravating factor, which is the third time this year I've written about data outliving its purpose.
And watch the order, not the number. I said the same about the DMA fine in July: for Alphabet the money is a line item, the behavioural remedy is the real instrument, and Google now has six months to change how it processes location data. Note the clock too. Opened February 2020, decided September 2026. Six and a half years, which is how long after the fact you can be asked to justify decisions made by people who have since left.
ISO 9001:2026 makes quality culture auditable. You can't write a procedure for that.
ISO published the sixth edition of ISO 9001 on 16 September, cancelling the 2015 version and absorbing the 2024 climate amendment. Ten clauses, same order, most of the text familiar, which is exactly the trap. Four things moved. Top management must now promote quality culture and ethical behaviour, and people working under your control have to be aware of it, which makes culture an audit topic assessed through interviews. Risks and opportunities split into separate clauses, each requiring you to determine, analyse and evaluate, then evaluated separately again in management review. Change management grows from four considerations to seven, adding communication of changes, monitoring their effectiveness and reviewing the results. And much of the documented information wording shifts from maintain and retain to "shall be available". The transition runs to 30 September 2029, when 2015 certificates expire.
Source: My full breakdown · cyberacademy.net
My take
A culture is not a procedure. You cannot write it, approve it and file it, and an auditor will not assess it by reading your policy page. They'll assess it by asking your people how defects get reported and whether anyone hesitates before raising bad news. Your defence is evidence of what management actually does: board minutes, decisions where quality beat schedule, what happened to the last person who escalated a problem. Collect it now, because you cannot reconstruct it later.
Two practical notes. Annex A.6.1.2 says risk-based thinking does not imply a formal risk management approach or a documented process, so if a consultant tells you the new version forces a risk register on you, they're selling something. And don't trust the three-year runway. Most organisations transition during a scheduled surveillance or recertification audit, and those slots fill from the certification body's side, not yours. Count backwards from your own cycle and you usually find one realistic window. The full clause-by-clause read is linked above.