JhumanJ OpnForm CVE-2025-11442
LOWSeverity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/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
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/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
Lifecycle Timeline
1DescriptionCVE.org
A security flaw has been discovered in JhumanJ OpnForm up to 1.9.3. The impacted element is an unknown function of the component API Endpoint. The manipulation results in cross-site request forgery. The attack may be performed from remote. The exploit has been released to the public and may be exploited. The vendor has stated that API calls require authentication through Authorization Bearer Tokens, so classic CSRF attacks do not apply here. An attacker would need to possess the JWT through means such as XSS which were mitigated, disabling any form of initial access.
AnalysisAI
OpnForm up to version 1.9.3 contains a cross-site request forgery vulnerability in an undisclosed API endpoint, though the practical exploitability is severely constrained by the vendor's mandatory use of JWT Bearer token authentication. The vulnerability requires an attacker to first obtain a valid JWT token through a separate XSS attack, which the vendor states has been mitigated in the product, making the CSRF itself a secondary concern rather than an independent attack vector. Publicly available exploit code exists, but real-world impact is minimal given the authentication and XSS mitigation barriers.
Technical ContextAI
OpnForm is a form management and API endpoint system. The vulnerability stems from insufficient CSRF protections (CWE-352) on an unnamed API endpoint, a classic web application flaw where state-changing requests lack proper anti-CSRF tokens. However, the underlying architecture mitigates the traditional CSRF threat model by requiring JWT Bearer token authentication on all API calls. JWT tokens are session/user-specific credentials that cannot be exploited via cross-site request forgery in the classical sense (browsers cannot automatically include Authorization headers in cross-origin requests). The vulnerability's practical impact thus depends entirely on the attacker's ability to first compromise a user session via XSS to steal the JWT token, after which the CSRF protection gap becomes exploitable. The CPE cpe:2.3:a:jhumanj:opnform:*:*:*:*:*:*:*:* indicates the flaw affects all versions up to and including 1.9.3.
RemediationAI
Upgrade OpnForm to version 1.9.4 or later as soon as the vendor releases a patched version, which should include hardened CSRF protections on the affected API endpoint and verification that XSS mitigations are effective. In the interim, perform a thorough code review of the unnamed vulnerable API endpoint to confirm JWT Bearer token validation is enforced on all state-changing requests (POST, PUT, DELETE) and cannot be bypassed via referer/origin manipulation. Verify that Content-Security-Policy headers are correctly configured to prevent XSS (script-src, object-src, and base-uri directives), and test for stored and reflected XSS vulnerabilities across form inputs and API response handling. If the organization cannot patch immediately, implement network-level mitigations such as restricting direct API access to known internal IPs and requiring additional authentication layers (e.g., mutual TLS or SAML) for API calls, though these add operational friction and do not address the root cause. Monitor for signs of unauthorized API modifications (audit logs of state-changing requests) to detect if exploitation occurs despite mitigations.
Share
External POC / Exploit Code
Leaving vuln.today