Which versions of Axelor Open Platform are affected by CVE-2026-63085?

Axelor Open Platform 8.x contains a privilege escalation vulnerability for which publicly available exploit code exists, enabling any authenticated user to escalate to administrator privileges and…. A patch is available.

Is there a public PoC exploit available for CVE-2026-63085?

Yes, a public proof-of-concept exploit is available for CVE-2026-63085. Prioritise patching immediately. EPSS: 0.4%.

How to fix or mitigate CVE-2026-63085?

Within 24 hours: inventory all Axelor Open Platform 8.x instances; restrict platform access to essential users only; enable detailed audit logging of user role and group modifications. Within 7 days: verify patch status with vendor; implement interim compensating controls including database-level write restrictions on protected User table fields and network-level access segmentation. Within 30 days: establish and verify sustained compensating controls; conduct forensic review of user administration logs for unauthorized privilege escalation attempts; maintain monitoring for vendor patch releases.

Axelor Open Platform CVE-2026-63085

Q: What is the CVSS score of CVE-2026-63085?

CVE-2026-63085 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

EUVD-2026-44950 HIGH

Incorrect Authorization (CWE-863)

2026-07-16 VulnCheck

GHSA-fgwg-8qwr-qvw3

Authentication Bypass Axelor Open Platform

8.7

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.8 HIGH

Network-reachable, low-complexity attack needing an existing non-admin account (PR:L) and no user interaction; admin takeover yields full C/I/A impact with no scope change.

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 (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jul 16, 2026 - 18:18 EUVD

Source Code Evidence Fetched

Jul 16, 2026 - 16:32 vuln.today

Analysis Generated

Jul 16, 2026 - 16:32 vuln.today

CVE Published

Jul 16, 2026 - 15:56 cve.org

HIGH 8.7

DescriptionCVE.org

Axelor Open Platform versions 8.x prior to 8.2.2 contains an authorization bypass vulnerability that allows authenticated non-admin users to escalate privileges by exploiting unenforced field restrictions on nested relational save operations. Attackers can modify sensitive User record fields such as roles and group by submitting changes through a related entity's save path, bypassing the USER_RESTRICTED_FIELDS control and causing the JPA persistence layer to flush attacker-supplied admin role and group assignments on commit.

AnalysisAI

Privilege escalation in Axelor Open Platform 8.x before 8.2.2 lets an authenticated non-admin user grant themselves administrative roles and groups by writing to protected User fields through a nested relational save on a related entity, bypassing the USER_RESTRICTED_FIELDS control. The flaw (CWE-863, improper authorization) was reported by VulnCheck and has publicly available exploit code; it is not listed in CISA KEV. With a CVSS 4.0 base score of 8.7 and full compromise of confidentiality, integrity, and availability of the vulnerable system, any low-privileged account can effectively become an administrator.

Technical ContextAI

Axelor Open Platform is an open-source low-code/ERP framework built on JPA/Hibernate for persistence. The platform enforces a USER_RESTRICTED_FIELDS control to prevent ordinary users from editing sensitive User attributes such as roles and group. The root cause is a CWE-863 improper authorization defect: the field-level restriction is applied on direct User save operations but not on nested relational save paths, where a User record is persisted as a related entity of another object. Because the JPA persistence layer flushes all dirty associations on transaction commit, attacker-supplied role and group assignments embedded in the nested payload are written to the database even though they were never authorized. The v8.2.2 release also reworked second-level caching for the User, Group, Role, and Permission regions and the User.roles/User.permissions/Group.roles association collections, underscoring that these auth associations are the sensitive data at stake.

RemediationAI

Vendor-released patch: 8.2.2 - upgrade Axelor Open Platform to v8.2.2 or later (release: https://github.com/axelor/axelor-open-platform/releases/tag/v8.2.2). This is the primary and recommended fix, as it enforces the field restriction across nested relational save paths. Where an immediate upgrade is not feasible, apply compensating controls: disable any self-service user registration so attackers cannot obtain the low-privileged account the exploit requires (trade-off: blocks legitimate onboarding); tightly restrict which low-privileged roles can invoke save/persist operations on entities that relate to the User record (trade-off: may break custom workflows that legitimately persist related User data); and audit/alert on any change to User.roles and User.group via application audit logging or database triggers to detect unauthorized admin grants quickly. Also review recent role/group assignment history for signs of prior abuse. Consult the VulnCheck advisory (https://www.vulncheck.com/advisories/axelor-open-platform-8-x-authorization-bypass-via-nested-relational-record-persistence) for details.