PHP2Shell sounds like a matter for the IT department. For a German subsidiary, it is also a bookkeeping issue: if its web shop or document repository runs on PHP, those systems fall within the scope of what the German tax office audits. This article takes the parent company's perspective: what the subsidiary is now obliged to do, and who in the group should initiate what.
What happened
“PHP2Shell” is the name given to two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) in PHP, the programming language behind many websites and online shops. The Federal Office for Information Security (BSI), Germany's cybersecurity authority, cites a severity rating of 9.2 out of 10: attackers could execute malicious code on web servers remotely, without logging in and without any user interaction. The patches were released on 21 October 2026 at 4 pm German time. The BSI is not yet aware of any confirmed exploitation; security firms are reporting the first attack attempts.
Whether your systems are affected is explained by our data centre partner DAVINCI Rechenzentrum in the article Am I affected by PHP2Shell? (in German).
Why a web server is part of your accounting
How electronic books must be kept in Germany is set out in the GoBD, a circular from the Federal Ministry of Finance that tax offices apply in their audits. Under the GoBD, the data processing system includes not only financial accounting but expressly also upstream and ancillary systems such as inventory management, point of sale, payments, invoicing, archiving and document storage, including the interfaces between them. Whether the hardware is your own or in the cloud makes no difference (GoBD Rz. 20, i.e. margin number 20).
In a group, these systems are often spread across several countries:
| System | Where it is typically run | Why it matters for tax |
|---|---|---|
| Web shop of the German company | with a hosting provider or in group IT | records orders, issues invoices |
| Parent company's ERP | in the parent's data centre, often abroad | takes over orders and intercompany invoices via interfaces |
| Document repository | cloud or own server | holds receipts and contracts that must be retained |
| Accounting in DATEV | in Germany, at the tax firm | takes over data from all upstream systems |
The flaw lies in PHP itself; according to security researchers, this means shops on Magento, Shopware or WooCommerce are vulnerable even if their own code is flawless. And if the parent's ERP does not run on PHP, manipulated orders can still reach it through an automated interface.
Who in the group is responsible
The German GmbH is a separate legal entity. Its managing directors must ensure proper bookkeeping (§ 41 GmbHG, the German Limited Liability Companies Act) and fulfil the company's tax obligations (§ 34 AO, the German Fiscal Code). This applies even if the managing director lives abroad and all IT sits with the parent company. The Federal Ministry of Finance states this explicitly:
“The taxpayer alone is responsible for the proper keeping of electronic books and other required electronic records […]. This also applies where bookkeeping and record-keeping tasks are outsourced to third parties, in part or in full, organisationally and technically (e.g. tax advisors or data centres).” (translation)
GoBD Rz. 21 · Federal Ministry of Finance (BMF) circular of 28.11.2019
From the subsidiary's perspective, the parent's group IT is precisely such a third party.
Group IT closes the vulnerability and preserves evidence. German management initiates this and documents the consequences for the books. The tax firm assesses what needs to be done vis-à-vis the tax office.
Four obligations a breach affects
- Immutability: An entry or record must not be altered in a way that makes its original content impossible to determine (§ 146 Abs. 4 AO, GoBD Rz. 108). After unauthorised write access, this can no longer be assumed without verification.
- Protection against loss: The system must be protected against loss and unauthorised alteration (GoBD Rz. 103). If data can no longer be produced as a result, the bookkeeping is formally no longer proper (Rz. 104). The consequences depend on the individual case (Rz. 105).
- Retention and data access: Books must be kept for ten years, accounting vouchers for eight years (§ 147 Abs. 3 AO). During a tax audit, termed “Außenprüfung” (external audit) in the statute, the tax office can access the data (§ 147 Abs. 6 AO), including data from upstream and ancillary systems (GoBD Rz. 159).
- Evidential value: The tax office bases taxation on proper bookkeeping unless there is reason to question its substantive accuracy (§ 158 AO). If it cannot determine the basis for taxation, it makes an estimate (§ 162 AO), taking into account all circumstances relevant to that estimate.
“An attack does not automatically render the books worthless. What counts in a tax audit is whether the company can show which data could have been affected and how it was restored and reconciled. The German company must be able to provide that evidence itself, not just the parent's IT.”
Fatma Tabak, tax advisor · TABAK Steuerberatung
Reconstruction: which data matters now
It starts with a date: the earliest point from which a system can no longer be considered trustworthy. From that follows:
- Up to the cut-off date, data comes from a clearly dated backup taken before the incident.
- From the cut-off date, it is reconciled against sources outside the affected system: bank transactions, statements from payment service providers and marketplaces, invoices sent. In a group, additionally: the intercompany charges in the parent's ERP.
- Re-entries remain identifiable: Reconstructed data must not look as though it had originally been recorded that way (§ 146 Abs. 4 Satz 2 AO, GoBD Rz. 111).
- The reconciliation is retained: which source, which period, which discrepancies.
“In many groups, IT sits with the parent while the obligations sit with the German subsidiary. After PHP2Shell, someone in Germany therefore needs to know which systems could have been affected, from when they were no longer trustworthy and where the clean backup is. For the accounting, too, that date is the single most important figure.”
Metehan Kurt, IT consultant · DAVINCI Rechenzentrum
Rebuilding at the parent? Check § 146 AO first
Rebuild the shop or document repository at the parent after the incident? From a tax perspective, that is not a free choice. Books and records must, as a rule, be kept and retained in Germany (§ 146 Abs. 2 AO). Electronic records may also be held in another EU member state, provided the tax office retains full data access (§ 146 Abs. 2a AO). For a country outside the EU, the company needs approval from the tax office (§ 146 Abs. 2b AO). Relocating without approval risks a delay penalty of 2,500 to 250,000 euros (§ 146 Abs. 2c AO).
If approval already exists, any change to the notified system location must be reported to the tax office without delay (§ 146 Abs. 2b Satz 4 AO). The basics are covered in our article Understand Your German Subsidiary in 15 Minutes.
Does the subsidiary have to inform the tax office?
Neither the Fiscal Code (AO) nor the GoBD contains a general obligation to report an attack or data loss on your own initiative. The company must act, however, in two situations:
- Incorrect return identified: If it turns out that a return already filed, such as an advance VAT return, is incorrect because of altered data and tax may be understated, this must be reported and corrected without delay (§ 153 Abs. 1 AO).
- Ongoing tax audit: In audits ordered since 2025, following a qualified request for cooperation, the tax office can impose a cooperation delay penalty of 75 euros per day, for a maximum of 150 days (§ 200a Abs. 2 AO). It must refrain from doing so if the delay is excusable. If data is missing, the company should point this out without delay (§ 200a Abs. 4 AO).
Notifications to a data protection supervisory authority are a separate question; for customer data and invoices of an online shop, see Selling online in Germany after PHP2Shell. On the costs of the incident: PHP2Shell incident: claiming the costs for tax purposes.
The incident belongs in the procedural documentation
The procedural documentation (Verfahrensdokumentation) describes how bookkeeping works technically and organisationally. It must record all system and process changes without gaps (GoBD Rz. 150), versioned and matched to the software versions in use (Rz. 154). After PHP2Shell, something almost always changes: PHP version, server, credentials, often the backup status. Missing documentation is not a formal defect of substantive weight, provided traceability and verifiability are not impaired (Rz. 155). After an attack, that is exactly the open question. More on this in our GoBD Checklist.
What management should initiate now
- Obtain written confirmation (from group IT or the hosting provider) of which subsidiary systems run on PHP and when they were updated.
- Secure statements from banks, payment service providers and marketplaces for October 2026 outside the affected systems.
- If a breach is suspected, determine the cut-off date and agree the reconstruction with the tax firm.
- Check § 146 AO before moving any systems abroad.
- Record the update, cut-off date, backup status and reconciliation in the procedural documentation.
We bring IT and accounting together: DAVINCI Rechenzentrum handles the technical side, our partner tax firm TABAK Steuerberatung the tax side. We advise you in English — directly, without intermediaries.
Frequently Asked Questions
Does our German subsidiary have to report a PHP2Shell incident to the tax office?
There is no general reporting obligation. However, if a return already filed is incorrect because of altered data, the company must report and correct this without delay (§ 153 AO).
Our IT sits with the parent company. Who is responsible to the tax office after PHP2Shell?
The German company, represented by its managing directors (§ 41 GmbHG, § 34 AO). Outsourcing to third parties does not change this (GoBD Rz. 21).
Is the bookkeeping still proper after a PHP2Shell attack?
It is not automatically unusable. It is formally no longer proper if data can no longer be produced due to a lack of protection; the consequences depend on the individual case (GoBD Rz. 104, 105).
May we rebuild the shop in the parent's data centre in China after PHP2Shell?
Only with approval from the tax office, insofar as books or records required for tax purposes are kept or stored there (§ 146 Abs. 2b AO). Otherwise a delay penalty may be imposed (§ 146 Abs. 2c AO).
What happens if the subsidiary's data is lost due to PHP2Shell?
The tax office can estimate the basis for taxation (§ 162 AO). What then counts is a documented reconstruction from backups, bank and payment data and intercompany charges.
Sources
- BSI cybersecurity warning of 21.10.2026: PHP – critical vulnerabilities threaten web applications worldwide
- BMF, Official AO Handbook 2025, Annex 33 – GoBD
- § 34 AO – Duties of legal representatives
- § 41 GmbHG – bookkeeping
- § 146 AO – Rules on proper bookkeeping (Abs. 2, 2a, 2b, 2c, 4)
- § 147 AO – retention of records, data access
- § 153 AO – Correction of returns
- § 158 AO – Evidential value of bookkeeping
- § 162 AO – Estimation of the basis for taxation
- § 200a AO – Qualified request for cooperation
PHP2Shell in your German company?
We work with your group IT to establish which subsidiary systems may be affected, and make sure the accounting and procedural documentation reflect the incident. The tax assessment is handled by our partner tax firm TABAK Steuerberatung.