- On 21 October 2026, PHP released fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619 (“php2shell”; CVE means Common Vulnerabilities and Exposures), each rated 9.2 on the Common Vulnerability Scoring System (CVSS) v4. Both can allow remote code execution without logging in. (PHP advance notice, 20 October 2026; PHP security advisory, 21 October 2026)
- PHP announced the release a day ahead and withheld the details until the fix shipped, so PHP-based platforms had to protect themselves without a patch, relying on their own code knowledge and security-firm reports. (PHP advance notice, 20 October 2026)
- JomeInvoice applied a safeguard to every production server by 17:14 Malaysia time on 21 October, more than 4 hours before PHP’s fix, and found no sign of attack, per its customer incident log of 23 October 2026.
- Appointing an e-invoice vendor does not transfer e-Invoice compliance responsibility: it stays with your company, and with its director. (LHDN (Lembaga Hasil Dalam Negeri Malaysia) e-Invoice General FAQs, 4 September 2026, Q30)
- Ask any vendor for evidence, not adjectives: a dated incident timeline, a protect-before-patch capability, rollback, post-incident checks, certifications and where your data is hosted.
e-Invoice software security is how a vendor protects your invoice data, your connection to MyInvois and your service uptime, including how fast it acts when a new threat appears. MyInvois is the e-Invoice validation system of LHDN (Lembaga Hasil Dalam Negeri Malaysia, the Inland Revenue Board of Malaysia, also called IRBM), covered in our complete guide to LHDN e-Invoicing. PHP gave advance notice of a security release for two critical flaws, later named php2shell; JomeInvoice logged that notice at 04:32 Malaysia time on 21 October 2026, and the fix arrived just over 17 hours later. For every e-invoice platform built on PHP, those 17 hours tested the response process, not the security brochure.
This matters to you because LHDN has no certification requirement for e-invoice providers at this juncture, and appointing one never moves your compliance responsibility. Below: what php2shell was, how JomeInvoice responded hour by hour, why your vendor’s security is your risk, and 8 questions to put to any e-invoice software vendor before you trust it with your invoices.
Verified against the LHDN e-Invoice General FAQs (updated 4 September 2026), the e-Invoice Specific Guideline v4.9 (7 September 2026), the e-Invoice General Guideline v4.8 (30 August 2026) and the PHP security notices of 20 and 21 October 2026, on 26 October 2026.
What Was php2shell, and Why Did It Matter for e-Invoice Platforms?
php2shell is the name given to two critical vulnerabilities in PHP, the programming language behind a large share of websites and web applications. PHP published both on 21 October 2026 as CVE-2026-109618 and CVE-2026-109619, each scored 9.2 out of 10 under CVSS version 4, which puts them in the Critical band. (PHP advance notice and security advisory, accessed 26 October 2026)
The PHP advisories describe two different bugs with the same outcome:
- CVE-2026-109618 (“RCE via OOM corruption”): a request that pushes PHP into an out-of-memory error can leave internal request data only partly set up, which an attacker can turn into remote code execution (RCE). (GHSA-w8hw-w9fx-j79w, accessed 26 October 2026)
- CVE-2026-109619 (“RCE via stale global state”): a PHP worker can keep internal state that points at memory freed after a previous request, and a later request can act on it. (GHSA-6wmf-4rv5-p3rp, accessed 26 October 2026)
- Shared impact: no login is needed, and code runs with the privileges of the web server’s worker account. Fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP states that only an update is a complete solution.
The timing was the real problem. PHP’s advance notice, dated 20 October 2026, scheduled the release for 21 October at 14:00 Coordinated Universal Time (UTC) and held back “full details, affected versions, and the fixed versions” until then. (PHP advance notice) JomeInvoice logged the notice at 04:32 Malaysia time (MYT) on 21 October; the GitHub advisories show a publication time of 13:34 UTC, or 21:34 MYT. Reports on exploitation were mixed: Tenable’s FAQ cites Amazon Threat Intelligence describing an exploitation attempt dated 17 October, while the US Cybersecurity and Infrastructure Security Agency (CISA) said on 21 October it had not yet observed exploitation. Amazon later reported broad exploitation in the wild. (Tenable php2shell FAQ, updated 23 October 2026, accessed 26 October 2026)
A PHP-based e-invoice platform is an attractive target in that window. It holds buyer and supplier details, Tax Identification Numbers (TINs), invoice amounts and the credentials it uses to submit to MyInvois on your behalf. A server takeover there is a data incident and a compliance incident at the same time.
How JomeInvoice Responded: A Timestamped Timeline
JomeInvoice put a safeguard on every production server 12 hours and 42 minutes after PHP’s notice was logged, and before the official fix existed. From the notice to final verification took about 25 hours, in five phases. The table below reproduces JomeInvoice’s incident log as sent to customers on 23 October 2026; all times are MYT.
| Phase | Date and time (MYT) | What happened |
|---|---|---|
| 1. Understand the threat | 21 Oct, 04:32 | JomeInvoice logged PHP’s advance notice of a critical security release. No fix available yet. |
| 1. Understand the threat | 21 Oct, morning | JomeInvoice started its response: reviewed PHP’s notice and security-firm reports, and studied how the attack works. |
| 2. Protect before a fix existed | 21 Oct, afternoon | Confirmed the JomeInvoice code does not rely on the PHP feature used by the main known attack path, so that feature could be switched off safely. |
| 2. Protect before a fix existed | 21 Oct, 16:54 | Switched the feature off on test environments first and confirmed JomeInvoice still worked normally. |
| 2. Protect before a fix existed | 21 Oct, 17:11 to 17:14 | Applied the same safeguard to every production server. |
| 2. Protect before a fix existed | 21 Oct, 17:28 | Checked all servers for signs of attack: changed program files, attack-tool code, suspicious files, crash signs. All clean. |
| 2. Protect before a fix existed | 21 Oct, 21:34 | PHP released the official fix; JomeInvoice reviewed the details the same evening. |
| 3. Add a web firewall layer | 21 Oct, 23:21 to 23:55 | Enabled extra web firewall protection on test environments, tested it with login, CSV and Excel invoice import, file uploads, application programming interface (API) calls and integration webhooks, then enabled it for all services. |
| 4. Install the official fix | 22 Oct, 00:23 to 00:27 | Updated the main platform with the fix; checked login, API and logs; restarted background jobs on the new version. |
| 4. Install the official fix | 22 Oct, 00:30 to 02:30 | Prepared the fix and a step-by-step update procedure for the other servers. |
| 4. Install the official fix | 22 Oct, 02:45 to 02:53 | Installed and checked the fix on test environments. All test sites working. |
| 4. Install the official fix | 22 Oct, 03:20 | Saved a full rollback copy on every remaining server and pre-downloaded the update to all of them. |
| 4. Install the official fix | 22 Oct, 03:49 to 04:52 | Updated every remaining server one at a time, each with automatic checks and automatic rollback ready. No rollback was needed. |
| 5. Verify | 22 Oct, about 05:00 | Reviewed every server’s logs: no errors from the update, no sign of attack. |
| 5. Verify | 22 Oct, 05:05 to 05:55 | Passed full automated test suites on the updated version, including e-invoice submissions to LHDN’s test system. |
For customers, the log records four outcomes:
- No action needed: everything was done on JomeInvoice’s side.
- No sign of any attack on JomeInvoice systems.
- Customer data was not affected, and service continued normally, with only a few seconds of restart per server.
- JomeInvoice services that do not use PHP were not affected.
What the timeline shows about a vendor’s security process
Three habits separate a tested process from a security statement:
- Protect before the patch. Knowing your own code well enough to switch off what the main known attack path needs, safely, within hours.
- Test before you roll out. The safeguard and the firewall rules ran on test environments before production, and the fix was tested before it reached the remaining servers, each with a rollback copy ready.
- Verify after. A compromise check right after the safeguard, log review after the update, and a full test run that included e-invoice submissions to LHDN’s test system.
When the next critical flaw lands before a fix, whose team acts?
For php2shell, JomeInvoice had a safeguard on every server before PHP’s fix. Talk to us about your setup.
Book a Demo Sign Up Free
Why Your e-Invoice Vendor’s Security Is Your Compliance Risk
Your vendor’s failure stays your compliance problem. LHDN’s position is explicit: when a company appoints a third-party service provider to manage its e-Invoice obligations, the responsibility to comply remains with the company, and for a company it rests with its director as defined in Section 2 of the Income Tax Act 1967. (General FAQs, 4 September 2026, Q30) We cover this in our guide on whether a business can outsource e-invoice submission to a third-party provider.
Three further LHDN positions make vendor security a buyer-side decision:
- No provider registration or certification, at this juncture. LHDN has no registration requirement for technology providers at this juncture, and no certification requirement either, although it says this may change. Providers are responsible for the functionality and reliability of their API integration with IRBM. (General FAQs, Q138 and Q139)
- Vendor-caused errors stay yours to fix. If a vendor causes e-Invoice non-compliance, the taxpayer may regularise it under the e-Invoice Special Voluntary Disclosure Programme (SVDP), open until 31 December 2027, but responsibility remains with the taxpayer. (General FAQs, Q129 and Q133; Specific Guideline v4.9, Section 17)
- Downtime rules cover MyInvois, not your vendor. LHDN states MyInvois will be available 99.97% of the time; when it is down, suppliers are given 72 hours to issue an e-Invoice once it is back, and a retry mechanism “shall be implemented” in the supplier’s system. (General FAQs, Q143) The FAQs do not address outages on your vendor’s side, so do not assume the same allowance applies.
LHDN secures its own side. The FAQs state that IRBM’s controls may include encryption, authentication, access control, backup, firewalls and logging, and that IRBM will ensure the system complies with and is certified to ISO/IEC 27001:2022 (the international information security management standard) and ISO 22301:2019 (business continuity management). (General FAQs, Q146 and Q147) None of that covers the vendor in the middle, which holds your credentials, your master data and your submission queue.
8 Security Questions to Ask Any e-Invoice Software Vendor
Use these 8 questions in vendor due diligence, a request for proposal (RFP) or an annual review. They work for any e-invoice software, e-invoice system or e-invoice middleware, including ours. A good answer is specific and dated; a weak answer is a list of adjectives.
| # | Question to ask | Why it matters | What a good answer looks like | Red flag |
|---|---|---|---|---|
| 1 | How fast did you act on your last critical vulnerability? Can you share the dated timeline? | Speed in the hours before a patch decides exposure. | A real incident with timestamps, from notice to verification. | “We take security seriously,” with no dates. |
| 2 | Can you protect systems before an official patch exists? | Critical flaws can be announced before a fix, as php2shell was. | A named mitigation path: switching off unused features, firewall rules, isolation. | “We apply patches when vendors release them.” |
| 3 | Do you test fixes on a separate environment before production? | Untested emergency changes can break invoicing. | A test environment that mirrors production, with your key flows tested. | Patches applied straight to live servers. |
| 4 | Do you keep rollback copies and update servers one at a time? | A bad update should never take every customer down at once. | Per-server rollback with automatic checks; staged updates. | One big update window, no rollback plan. |
| 5 | After an incident, how do you check for compromise, and will you tell us? | Patching does not remove an attacker who is already in. | A compromise check (changed files, suspicious code, logs) and a written customer notice. | No notice unless customers ask. |
| 6 | Which security certification covers the service we would use? | A certification shows an audited security management system, not just intent. | Current ISO/IEC 27001 certification, with a scope that covers the e-invoicing service. | A certification “in progress” for years, or one that covers a different business unit. |
| 7 | Where is our invoice data hosted? | Data location decides which cloud region and which country’s law your invoice records sit under. | A named cloud provider, region and country. | “In the cloud,” with no region named. |
| 8 | Who in our team can sign in, see and export our data? | A stolen password alone should not be enough to reach your invoicing account. | Single sign-on (SSO) with your company identity provider, and roles that limit what each user can view and export. | Shared logins, and every user with full access. |
A note on the PDPA
The Personal Data Protection Act 2010 (PDPA) has a specific carve-out for e-invoicing. Section 82C(11) of the Income Tax Act 1967 states that the PDPA does not apply to personal data processed for e-Invoices “issued or transmitted to the Director General under this section and any other related provisions of this Act”. (Income Tax Act 1967, s.82C(11); General FAQs, Q144) On its wording, the carve-out is tied to e-Invoice data; it does not mention the other personal data a vendor holds, such as user accounts and support records. Treat “PDPA compliant” as a relevant answer, not a sufficient one, and confirm the position for your business with your legal adviser.
The same 8 questions apply when you shortlist vendors from any comparison of the best e-invoice software in Malaysia, or when you weigh MyInvois portal vs API integration vs middleware. Some vendors cannot share incident detail under their disclosure policy; in that case, ask for the process and the target response times in writing.
How JomeInvoice Protects Your e-Invoice Data
JomeInvoice’s answer to questions 1 to 5 is the php2shell timeline above. For enterprises already live on another provider, or on an in-house integration, the security question is practical: when the next critical flaw is announced before a fix, whose team acts, and how fast?
JomeInvoice is a Malaysian e-invoicing middleware company headquartered in Kuala Lumpur and backed by AGMO Holdings Berhad. Its answers to the other questions:
- Same-day response: JomeInvoice monitors security advisories continuously and acts on critical issues the same day. For php2shell, that meant a safeguard on every production server before PHP’s fix, a staged update with rollback ready, and log review that found no sign of attack.
- Certifications (question 6): ISO 9001, ISO 20000-1 and ISO 27001 certified, and PDPA compliant. Ask for the certificates and their scope as part of your review.
- Data location (question 7): data hosted onshore on Amazon Web Services (AWS) in Malaysia.
- Access control (question 8): Enterprise SSO with Microsoft, Google or any OpenID Connect (OIDC) identity provider, and user roles where Export is granted separately from View, so read-only staff cannot pull data out.
- Reliability: 99.999% historical uptime with an automatic retry mechanism, so submissions resume when MyInvois returns.
- People: a dedicated enterprise account manager, and support in Bahasa Malaysia, English and Mandarin from a Malaysian team.
Switching does not mean replacing your systems. JomeInvoice custom-integrates with your existing enterprise resource planning (ERP), point-of-sale (POS) or accounting system and takes over the MyInvois connection and LHDN updates. Enterprise go-live typically takes 4 to 8 weeks, subject to change where more complicated or customised solutions are needed. See how the enterprise e-invoicing solution works, then book a session to assess your current setup against the 8 questions.
Frequently Asked Questions
Q: Is e-invoice software safe to use in Malaysia?
A: Yes, when the vendor can show evidence. Ask for a dated incident timeline, current ISO/IEC 27001 certification covering the service, the hosting region and access controls such as single sign-on. LHDN has no certification requirement for providers at this juncture, so the buyer must check. [General FAQs Q138, Q139]
Q: What was php2shell?
A: php2shell is the name for two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026 and rated 9.2 under CVSS v4. Both can allow remote code execution without logging in. Fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. [PHP advance notice, 20 October 2026; PHP security advisory, 21 October 2026]
Q: Did php2shell affect JomeInvoice customer data?
A: No. JomeInvoice found no sign of attack, and customer data was not affected. A safeguard was on every production server by 17:14 MYT on 21 October 2026, before PHP’s fix, and every server was updated by 04:52 MYT on 22 October.
Q: Did JomeInvoice customers need to do anything after php2shell?
A: No. All work was done on JomeInvoice’s side. The updates ran overnight with only a few seconds of restart per server, and service continued normally.
Q: If my vendor’s problem causes missed or wrong e-Invoices, who is responsible to LHDN?
A: Your company, and for a company, its director. Responsibility stays with the taxpayer even when a provider is appointed. The e-Invoice SVDP, open until 31 December 2027, can regularise vendor-caused errors, except where fraud, wilful default or negligence is involved. [General FAQs Q30, Q133; Specific Guideline v4.9 S.17.4]
Q: Does LHDN certify e-invoice software providers?
A: No, not at this juncture. LHDN has no registration or certification requirement for technology providers, though it says this may change. Providers must ensure the functionality and reliability of their API integration with IRBM. [General FAQs Q138, Q139]
Q: Where is JomeInvoice data stored?
A: Onshore in Malaysia, on Amazon Web Services (AWS) Malaysia. JomeInvoice is also ISO 27001 certified and PDPA compliant.
Q: How do I control who can access our JomeInvoice workspace?
A: Set up Enterprise SSO under Settings, Workspace Settings, Single Sign-On. Create roles under Settings, Workspace Settings, User Roles, and assign them under Settings, People. Export is granted separately from View, so view-only staff cannot pull data out.
Security claims are cheap. Timelines are not.
php2shell gave every PHP-based e-invoice platform 17 hours with no patch available. Ask your vendor for its timeline, and remember that under LHDN’s rules, the compliance outcome is still yours.
Put your e-invoice vendor to the 8-question test
Book a session with JomeInvoice. We will walk through our own answers and assess your current setup.
Book a Demo Sign Up Free
Disclaimer: This article is for general informational purposes only and does not constitute legal or tax advice. LHDN guidelines are subject to updates. Always refer to the latest official LHDN e-Invoice Guidelines at myinvois.hasil.gov.my and consult a qualified tax professional for advice specific to your business.
Last updated: 26 October 2026 | Written by Yinn Sheng Ng, Head of Marketing
References
- PHP, advance notice “Upcoming Critical PHP Security Release” (20 October 2026), accessed 26 October 2026: https://www.php.net/archive/2026.php#2026-10-20-1
- PHP, “Security advisory: Critical remote code execution vulnerabilities, update now” (21 October 2026), accessed 26 October 2026: https://www.php.net/archive/2026.php#2026-10-21-5
- PHP, security advisory GHSA-w8hw-w9fx-j79w, CVE-2026-109618 “RCE via OOM corruption” (21 October 2026), accessed 26 October 2026: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- PHP, security advisory GHSA-6wmf-4rv5-p3rp, CVE-2026-109619 “RCE via stale global state” (21 October 2026), accessed 26 October 2026: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Inland Revenue Board of Malaysia, e-Invoice General FAQs (updated 4 September 2026), Q30, Q129, Q133, Q138, Q139, Q143, Q144, Q146 and Q147: https://www.hasil.gov.my/wp-content/uploads/lhdnm-e-invoice-general-faqs.pdf
- Inland Revenue Board of Malaysia, e-Invoice Specific Guideline Version 4.9 (7 September 2026), Section 17 (including 17.4): https://www.hasil.gov.my/wp-content/uploads/IRBM-e-Invoice-Specific-Guideline.pdf
- Inland Revenue Board of Malaysia, e-Invoice General Guideline Version 4.8 (30 August 2026): https://www.hasil.gov.my/wp-content/uploads/IRBM-e-Invoice-Guideline.pdf
- Inland Revenue Board of Malaysia, Income Tax Act 1967 (Act 53), consolidated, sections 2 and 82C(11): https://www.hasil.gov.my/wp-content/uploads/20240521-akta-cukai-pendapatan-1967-akta-53.pdf