CVE-2026-47168: Authenticated PHP Object Deserialization in EspoCRM

Overview

A critical insecure deserialization vulnerability has been disclosed in EspoCRM, an open source customer relationship management application. Tracked as CVE-2026-47168 and rated CVSS 9.1 (Critical), the flaw allows an authenticated administrator to supply crafted serialized PHP object data that EspoCRM stores in background MassAction or Export parameters and later deserializes without restricting which classes may be instantiated.

The issue affects all EspoCRM versions prior to 9.3.7, the version in which the vendor shipped a fix. EspoCRM published the fix alongside several other security patches in the same release (CVE-2026-46691, CVE-2026-46694, and CVE-2026-46708), tracked under GitHub Security Advisory GHSA-7q78-jjr9-mqcg.

Technical Details

How It Works

EspoCRM's background-job subsystem processes long-running MassAction operations (bulk updates/deletes across records) and Export jobs (bulk data exports) by persisting their parameters for later, asynchronous processing. According to the vendor's advisory, an authenticated administrator can supply crafted serialized PHP object data as part of those stored parameters. When the background process later picks up the job, it deserializes the stored data to reconstruct the parameters it needs — and the deserialization paths involved do not restrict which PHP classes are allowed to be instantiated during that process.

This matters because PHP's native unserialize() function, when given a serialized object of an arbitrary class, will instantiate that class and automatically invoke certain "magic methods" the class defines — such as __wakeup(), __destruct(), or __toString() — without any explicit call from the surrounding code. This behavior is the basis of the long-established PHP Object Injection (POI) exploitation technique: an attacker who can control the class name and property values inside a serialized payload, and who can reach a class (anywhere in the application's autoloaded codebase or its Composer dependencies) whose magic methods produce an exploitable side effect, can chain those side effects into arbitrary code execution. This chaining of otherwise-benign magic methods into a working exploit path is commonly referred to as a "gadget chain." Public technical write-ups on CVE-2026-47168 confirm the unrestricted deserialization and the MassAction/Export storage path as the root cause, but do not identify a specific confirmed gadget chain within EspoCRM's codebase — so organizations should treat the vulnerability as capable of RCE wherever a usable chain exists, rather than assume no chain is reachable.

Because the attacker must already hold administrator-level credentials to reach the vulnerable storage path, this is not an unauthenticated flaw. However, the CVSS vector's Scope: Changed rating reflects that successful exploitation can impact components beyond the vulnerable one — consistent with code execution escaping the application's own security boundary into the underlying server.

Impact Assessment

Who Is At Risk

• Any organization running a self-hosted EspoCRM instance on a version prior to 9.3.7
• Deployments where administrator accounts are shared, weakly protected, or have been previously compromised via credential stuffing, phishing, or an unrelated privilege-escalation bug
• Multi-tenant or managed-service environments where EspoCRM is offered to multiple customer organizations, each with their own administrator — since a malicious or compromised tenant admin could pivot to the host
• Instances that grant admin-level access to third-party integrators, contractors, or automation accounts more broadly than necessary

Potential Attack Chain

1. Access — Attacker obtains or already holds valid administrator credentials for a target EspoCRM instance (via credential theft, insider access, or chaining a separate privilege-escalation vulnerability)
2. Payload Crafting — Attacker builds a malicious serialized PHP object payload targeting a class with an exploitable magic method reachable in EspoCRM's codebase or dependencies
3. Storage — Attacker submits the payload as part of a MassAction or Export job's parameters, which EspoCRM persists for background processing
4. Deserialization — The background worker later retrieves and deserializes the stored parameters without validating the object's class, instantiating the attacker's chosen class and triggering its magic methods
5. Code Execution — If a usable gadget chain exists, the attacker achieves arbitrary PHP code execution in the context of the web application/background worker process, enabling webshell deployment, database access (including stored customer and CRM data), and lateral movement into the hosting environment

Mitigation

Immediate Actions

• Upgrade to EspoCRM 9.3.7 or later — this is the primary and vendor-recommended remediation, and it also carries fixes for three other CVEs (CVE-2026-46691, CVE-2026-46694, CVE-2026-46708) bundled in the same release
• Review administrator account inventories and remove or downgrade any accounts that do not require full admin privileges, reducing the pool of credentials that could be used to reach the vulnerable code path
• Rotate administrator credentials for any account suspected of compromise prior to patching
• Audit MassAction and Export job history in affected instances for jobs created by unfamiliar or unexpected administrator accounts around the disclosure window

Detection Opportunities

• Application and database logs showing MassAction or Export job creation with unusually large, malformed, or non-standard serialized parameter payloads
• Unexpected process spawning, file writes, or outbound network connections originating from the PHP-FPM/web server or background-job worker process
• New or modified files in the EspoCRM web root shortly after a MassAction/Export job runs
• Unfamiliar administrator logins or administrator-level API activity preceding suspicious job creation

Defence-in-Depth

• Restrict administrator account issuance to the minimum number of trusted individuals, and enforce multi-factor authentication on all admin accounts
• Run EspoCRM's PHP process under a least-privilege service account, with restricted filesystem write access outside of expected upload/cache directories
• Deploy PHP disable_functions hardening (e.g., disabling exec, shell_exec, system, passthru) to blunt the impact of a successful gadget chain even if one is found
• Keep EspoCRM and all Composer dependencies current — gadget chains for PHP object injection are frequently found in common third-party libraries, so patching those libraries closes avenues even when the core application's deserialization logic has not yet been hardened
• Segment EspoCRM's database and file storage from other production systems to limit lateral movement if the application server is compromised

Background

Insecure deserialization bugs like CVE-2026-47168 are a recurring class of vulnerability in PHP web applications, because unserialize() on untrusted or semi-trusted data is unsafe by default unless the caller explicitly restricts allowed classes (PHP's allowed_classes option). Background job queues and export pipelines are a common place for this pattern to surface, since job parameters are often serialized for storage and later deserialized by a worker process with fewer input checks than a typical HTTP-facing endpoint. The requirement for administrator-level access narrows the practical blast radius compared with an unauthenticated flaw, but it does not eliminate the risk — compromised or over-privileged admin accounts are common in real-world incidents, and this bug gives such an account a path to full server compromise rather than just application-level abuse.

References

• NVD — CVE-2026-47168
• GitHub Security Advisory GHSA-7q78-jjr9-mqcg
• EspoCRM Release 9.3.7
• Strix.ai — CVE-2026-47168 Technical Analysis