What is the CVSS score of CVE-2025-62368?

CVE-2025-62368 has a CVSS 3.1 base score of 9.0 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H. EPSS exploitation probability: 1.6%.

Which versions of Taiga are affected by CVE-2025-62368?

A critical remote code execution flaw (CVE-2025-62368, CVSS 9.0) affects Taiga project management deployments running version 6.8.3 or earlier, allowing crafted data submitted to the Taiga API to…

Is there a public PoC exploit available for CVE-2025-62368?

Yes, a public proof-of-concept exploit is available for CVE-2025-62368. Prioritise patching immediately. EPSS: 1.6%.

How to fix or mitigate CVE-2025-62368?

Within 24 hours, inventory every Taiga instance in the environment and confirm version (6.8.3 or earlier is affected), then reduce exposure by placing the Taiga API behind VPN or IP allow-listing, disabling self-registration, and restricting API access to trusted networks; enable verbose API and application logging and alerting for unexpected deserialization or process-spawning activity. Within 7 days, upgrade all affected instances to Taiga 6.9.0 (the vendor-released fix version), re-verify the version post-upgrade, rotate Taiga application secrets, database credentials, API tokens, and any integration keys stored on or reachable from Taiga hosts, and audit accounts for unnecessary privileges or stale/low-privileged users that could be leveraged. Within 30 days, complete migration of any remaining systems that cannot be upgraded (including hosted or third-party-managed instances), validate that self-registration and API exposure settings meet policy, run a compromise-assessment review of logs from the exposure window, and fold Taiga into routine critical-vulnerability tracking with defined patch SLAs.

Taiga CVE-2025-62368

CRITICAL

Deserialization of Untrusted Data (CWE-502)

2025-10-28 security-advisories@github.com

RCE Deserialization

9.0

CVSS 3.1 · Vendor: github

Severity by source

Vendor (github) PRIMARY

9.0 CRITICAL

AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

vuln.today AI

8.8 HIGH

Network-reachable API deserialization needing a valid account (PR:L) but no victim interaction (UI:N); RCE in the app context gives full C/I/A, scope unchanged (S:U) absent evidence of cross-component impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Oct 08, 2026 - 11:41 vuln.today

CVE Published

Oct 28, 2025 - 21:15 cve.org

CRITICAL 9.0

DescriptionCVE.org

Taiga is an open source project management platform. In versions 6.8.3 and earlier, a remote code execution vulnerability exists in the Taiga API due to unsafe deserialization of untrusted data. This issue is fixed in version 6.9.0.

AnalysisAI

Remote code execution in Taiga 6.8.3 and earlier allows an authenticated attacker to run arbitrary code on the server by submitting crafted serialized data to the Taiga API. The flaw is a CWE-502 unsafe deserialization issue rated CVSS 9.0 by the vendor and fixed in version 6.9.0. EPSS is 1.55% (74th percentile) and there is no public exploit identified at time of analysis; this CVE is not in CISA KEV, so risk is highest for unpatched instances that allow self-registration or host many low-privileged accounts.

Technical ContextAI

The root cause is CWE-502, Deserialization of Untrusted Data, in the Taiga API: the application accepts serialized objects from a client and reconstructs them without sufficient validation, allowing an attacker-supplied payload to influence object instantiation or execution paths and achieve remote code execution. Taiga is an open-source project management platform, and the vulnerability affects the API component in versions 6.8.3 and earlier. No CPE strings were supplied in the input data, so affected installs must be identified by product and version. The vendor's CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H) indicates network reachability, low attack complexity, low privileges required, and user interaction; our independent assessment drops UI to None and scope to Unchanged (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), since an API deserialization flaw normally requires no victim interaction - the UI:R discrepancy should be confirmed against the vendor advisory before down-weighting risk.

Affected ProductsAI

Taiga versions 6.8.3 and earlier are affected, specifically the Taiga API; version 6.9.0 is the first fixed release. No CPE strings were provided in the source data, so affected installs must be identified by product name and version rather than by CPE matching. The vendor advisory is GHSA-cpcf-9276-fwc5, referenced by NVD at the GitHub URL https://github.com/taigaio/taiga-back/security/advisories/GHSA-cpcf-9276-fwc5. Because Taiga is an open-source, self-hosted project management platform, exposure is concentrated in organizations running their own unpatched instances, and deployments that enable self-registration widen the pool of accounts an attacker could use to reach the vulnerable API.

RemediationAI

Upgrade to Taiga 6.9.0, the vendor-released patch version that resolves the unsafe deserialization in the Taiga API (vendor advisory: https://github.com/taigaio/taiga-back/security/advisories/GHSA-cpcf-9276-fwc5). Until upgrading, compensating controls include disabling self-registration so unauthenticated outsiders cannot obtain the low-privileged account required by the CVSS PR:L vector (trade-off: blocks legitimate new user sign-ups), restricting Taiga API network exposure to trusted internal networks or a VPN and blocking public access to the API endpoints (trade-off: breaks external integrations and remote access), and auditing existing low-privileged accounts for unexpected or stale users. No vendor-released patch delay is indicated - the fix exists in 6.9.0 - and no public exploit code was identified at time of analysis, so prioritization should focus on internet- or broadly reachable unpatched instances with many or self-registered accounts.