Over 80,000 organisations hit by PHP breach: *what it means for your logs*

Credentials stolen, shadow AI exposed

Over 80,000 organisations have had login credentials to AI services stolen, following critical vulnerabilities in PHP that went unpatched ^[1]. The stolen credentials include access to platforms such as ChatGPT, Claude and Gemini. Sweden's data protection authority, IMY, has warned organisations that the breach highlights two risks: the technical one, which is being patched, and the organisational one, which is harder to fix ^[1].

That second risk is shadow AI: people using AI tools without the organisation knowing. When an employee logs into an AI service with their work email and pastes in customer data, contract drafts or health records, the organisation has a data protection incident on its hands. If it doesn't know the tool exists, it can't detect the breach, secure the account or work out what data has been exposed.

Think of it like the office printer. Everyone knows it exists, someone keeps an eye on who uses it, and if it breaks the IT team hears about it. Shadow AI is the printer nobody told IT about, tucked away in a corner and connected to the guest network. By the time someone notices, half the department has been using it for months.

What the law says

GDPR requires organisations to protect personal data against unauthorised access and alteration ^[2]. When a breach happens, they must notify the supervisory authority without undue delay and, where feasible, within 72 hours. If the breach is likely to result in a high risk to people's rights, those affected must be told as well.

Sweden's Cybersecurity Act, which implements the EU's NIS2 directive, applies to essential and important entities across 18 sectors ^[3]. It requires them to manage ICT security risks and to report significant incidents in three stages: an early warning within 24 hours of becoming aware of the incident, an incident report within 72 hours, and a final report within a month.

Both regimes put weight on logs. GDPR Article 32 calls for measures to ensure the ongoing confidentiality, integrity and availability of processing systems, which includes being able to show what happened during a breach. The Cybersecurity Act's technical standard on ICT risk, borrowed from DORA, says logs must be protected against tampering, deletion and unauthorised access.

The evidence problem

Logs are what tell you when someone first accessed a compromised account, which files they opened and when the breach was detected. That last one matters, because reporting deadlines count from when you became aware, not from when it suits you.

The problem is that logs are kept by the same people who could change them. Say an investigation six months later asks why the early warning went out after 30 hours instead of 24. A log you could quietly edit, or one kept on a system your IT team administers, is easier to challenge than one with an independent record that it hasn't changed.

Access controls and monitoring are the foundation. Sealing log segments as they are written goes one step further, because a change shows up even when it's made by someone with the right access.

How a digital witness works here

A digital witness doesn't replace your logging system. It gives you a checkable record that a log segment existed at a certain time and hasn't changed since.

Here's what gets sealed: log segments at short intervals, say every few minutes, covering detection events, access attempts and incident reports as they are written. Your system sends a fingerprint of each segment to WitniumChain, not the segment itself, and gets a witness ID back. The segment stays in your systems. To check it later, you calculate the fingerprint again and compare it with the sealed one. If they match, nothing has changed. Change a single character in the log and the fingerprints won't match.

Internal audit, supervisors and incident responders can check the sealed segments without needing to trust whoever keeps the logs. That's useful when the question is whether anyone with admin rights edited the access log during the response.

What it doesn't do: it doesn't replace access control, monitoring or backups, and it doesn't show that the log is complete. It shows that what you sealed is what you have now.

You can start with the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free. Read the docs.

What this means for you

If you run IT or security: patch the PHP vulnerabilities if you haven't already ^[1]. Then ask whether you know which AI tools people in the organisation are using, and whether your logging captures when someone pastes data into an external service. If the answer to either question is no, shadow AI is a risk worth addressing before the next breach.

If you handle incidents: when the clock starts on a 24-hour or 72-hour deadline, the first thing a supervisor or an auditor will ask for is the log showing when you detected the breach. Decide now who keeps that log, how it's protected and who can check it.

If you're responsible for GDPR or NIS2 compliance: sealed log segments give you a record you can show to IMY, an auditor or a court without relying on trust. It's a short step to add to your incident response plan, and it pays off the day someone questions your timeline.

Sources

1. "Kritiska sårbarheter i PHP hotar personuppgifter – IMY varnar organisationer", GDPR Sweden, 2025-01-09, https://gdprsweden.se/nyheter/kritiska-sarbarheter-i-php-hotar-personuppgifter-imy-varnar-organisationer-mvuech9q
2. Regulation (EU) 2016/679 (GDPR), Articles 5(1)(c), 5(1)(f), 32 and 33, https://eur-lex.europa.eu/eli/reg/2016/679/oj
3. Cybersäkerhetslagen (2025:1506), implementation of NIS2 in Sweden, https://data.riksdagen.se/dokument/sfs-2025-1506.html
4. Commission Delegated Regulation (EU) 2024/1774 (DORA ICT risk technical standard), Article 12(2)(d), https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj