Last updated 26 October 2026. We will update this post if anything changes.
What happened
On 21 October 2026 the PHP project released emergency fixes for two critical vulnerabilities in the PHP interpreter itself, now known collectively as PHP2Shell:
- CVE-2026-109618: remote code execution through out-of-memory handling corruption.
- CVE-2026-109619: remote code execution through stale request state reused by a later request.
Both are rated 9.2 (Critical) on CVSS v4.0. They sit below the application layer, so they affect every web-facing PHP installation regardless of the framework or CMS on top of it. An attacker needs no account and no special access, and researchers have shown that the same flaws can expose live server memory, including credentials and API keys, without executing any code. Exploitation attempts were observed before the public disclosure, and governments, hosting providers and large platforms took services offline while they patched.
Authoritative references: the PHP project advisory, the CVE records for CVE-2026-109618 and CVE-2026-109619, and the technical write-up by the researchers who found the flaws at Wiz.
What it means for TelQ customers
The TelQ Testing Platform is not affected, and never was.
TelQ does not use PHP in any part of the platform: not in the web application, not in the public API, not in the SMS, voice and number-testing infrastructure. There was no window of exposure before the fixes were published, because there was nothing to fix. No customer data, API credentials or test results held by TelQ were reachable through these vulnerabilities at any point.
We did not take that on trust. When the first reports appeared we ran a full review: every production service and its container image, every server, every serverless function and every public hostname TelQ operates was checked for PHP. We also reviewed each vendor that handles customer data on our behalf against their own published advisories. None has reported an incident. The vendor-by-vendor summary is at the end of this post.
How we approach security
TelQ was not spared by PHP2Shell because of a last-minute decision. It was spared because of choices that were made years ago and are maintained deliberately:
- A small technology surface. The platform is API-first and runs on a single, strongly typed, JVM-based stack, hosted in German data centres under GDPR. We do not add runtimes, frameworks or vendors without a reason, because every one of them is something we have to patch, monitor and answer for.
- An inventory we can actually query. Services are built from versioned container images and infrastructure is defined as code, so "do we run X anywhere?" is a question we can answer with evidence in hours, not a question we have to guess at. That is what made this review fast.
- Vendors we can name. Every sub-processor that touches customer data is listed at telqtele.com/sub-processors, vetted before onboarding and reviewed again when something like this happens.
- Controls customers can see. Two-factor authentication, sub-accounts with scoped permissions and audit logs are part of the product, and our data security policy is public.
None of this makes TelQ immune. The next vulnerability may land somewhere we do depend on, and then the measure will be how quickly we know, how clearly we tell you, and what we change afterwards. This post is the first instance of a practice we intend to keep: when a credible vulnerability could affect our customers, we publish a dated statement, whether the news is good or not.
If you integrate with TelQ from a PHP application
The vulnerability is in the PHP interpreter, not in any library. If your own systems call the TelQ API from PHP, whether through our PHP SDK or direct HTTP calls, your server is in scope, and an attacker who exploits it can read the credentials it holds, including your TelQ API key.
We recommend:
- Update PHP now to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's patched package. PHP 8.1 and older have no supported fix; plan a migration to 8.2 or later.
- Rotate your TelQ API key if the integration ran on an internet-facing PHP server that was unpatched at any time after 17 October 2026. You can do this from your account settings or by contacting support.
- Review your TelQ usage for the same period and tell us if you see tests, destinations or volumes you do not recognise.
The TelQ SDK itself contains no vulnerable code and needs no update for this issue.
One further note for PHP operators: on 23 October the PHP project published an informational advisory for a related, lower-likelihood issue, CVE-2026-115560, which is not yet fixed in the releases above. It only applies to applications that configure a non-default session serialize handler and switch it back at runtime before session_start(), with upload progress enabled. The project's recommended mitigation until the next regular release is session.upload_progress.enabled=0, set in php.ini, an FPM pool or server configuration. If you already applied that setting on 21 October, keep it.
Where our sub-processors stand
TelQ publishes its sub-processors at telqtele.com/sub-processors. We checked each of them against its own published advisory, trust centre or status page. The table reflects their public positions as of 26 October 2026. "No public statement" means the vendor has not published anything about PHP2Shell; for vendors whose platforms are not built on PHP that is the expected outcome, not a warning sign. Where a vendor has not published a conclusive statement, we are awaiting more information and will update this table as it arrives.
| Vendor | Role for TelQ | Published position | Impact on TelQ customer data |
|---|---|---|---|
| Amazon Web Services | Cloud hosting (EU) | Bulletin 2026-143-AWS, 21 Oct, updated 23 Oct: "AWS services are not impacted." | None |
| Cloudflare | DNS, edge proxy and web application firewall | Blog, 21 Oct, updated 23 Oct to cover CVE-2026-115560: protections for all plans live before public disclosure; Cloudflare's own runtime products are not PHP | None |
| Datadog | Application monitoring | Trust Center, 21 Oct: "no impact to Datadog"; the platform "does not run PHP-based services" | None |
| Elastic | Search and audit logging | Detection guidance only; Elasticsearch is Java-based and no Elastic product advisory exists | None |
| Mailgun (Sinch) | Transactional email (EU) | Customer PHP Security Vulnerabilities FAQ, Sinch, 23 Oct: some internet-facing Sinch systems ran affected PHP versions; public endpoints have been patched, taken offline or isolated behind WAF rules, internal remediation in progress; "we have not identified evidence of compromise, unauthorized access, or impact to customer accounts or customer data", review ongoing | None reported; we are awaiting more information on which Sinch services were affected |
| SendGrid (Twilio) | Backup email provider | No public statement | None reported; we are awaiting more information |
| Sentry | Error monitoring | No public statement; Sentry's platform is not PHP-based | None reported |
| Tableau (Salesforce) | Internal reporting | Salesforce Trust, 21 Oct: "no evidence of exploitation affecting Salesforce or customer data" | None |
| Atlassian | Support knowledge base, status page | No public statement; Atlassian's cloud products are Java-based | None reported |
| 1Password | Credential management for TelQ staff | No public statement | None |
We also reviewed the processors listed on the same page, which support TelQ's own operations such as support tooling, invoicing, internal notifications and office software. None of them has reported an incident either, and the full review is available to customers on request.
Questions
Security and compliance teams can reach us at support@telqtele.com for the full vendor review, including the vendors we use only for our own internal operations, or for our data security documentation. Platform status is always visible at status.telqtele.com.
