HIGH 7.3

CVE-2026-11435: SQL Injection in Jinher OA 1.0 – Unauthenticated Remote Code Access

Jinher OA 1.0 contains a SQL injection vulnerability in its nextselectplan.aspx file. An attacker can manipulate the httpOID parameter to inject malicious SQL commands, potentially compromising data confidentiality, integrity, and availability. The vulnerability requires no authentication and can be exploited over the network. Proof-of-concept code has been publicly disclosed.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.3 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Weaknesses (CWE)
CWE-74, CWE-89
Affected products
0 configuration(s)
Published / Modified
2026-06-06 / 2026-06-17

NVD description (verbatim)

A security vulnerability has been detected in Jinher OA 1.0. This affects an unknown function of the file nextselectplan.aspx. Such manipulation of the argument httpOID leads to sql injection. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

5 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-11435 is a SQL injection flaw (CWE-89) affecting Jinher OA 1.0's nextselectplan.aspx endpoint. The vulnerability stems from insufficient input validation on the httpOID argument, allowing an unauthenticated remote attacker to construct queries that access, modify, or delete database records. The CVSS v3.1 score of 7.3 reflects the network-accessible nature (AV:N) and lack of required privileges (PR:N), combined with moderate impact across confidentiality, integrity, and availability (C:L/I:L/A:L). Public disclosure and vendor non-response escalate operational risk.

Business impact

Organizations running Jinher OA 1.0 face immediate risk of unauthorized database access, potential data exfiltration, and system compromise without authentication barriers. The publicly disclosed exploit means attackers can readily weaponize this vulnerability. Business continuity depends on rapid remediation, as attackers could modify or delete mission-critical records stored in the OA system, disrupt document workflows, and compromise employee and customer data.

Affected systems

Jinher OA version 1.0 is confirmed vulnerable. The exact scope of affected deployments and whether later versions have patched this issue requires verification against Jinher's official advisory. Organizations should inventory all Jinher OA instances and confirm their version numbers immediately.

Exploitability

This vulnerability is highly exploitable. It requires no authentication, no user interaction, and no complex prerequisites—only network access to the nextselectplan.aspx endpoint. The CVSS Access Vector (AV:N) and Attack Complexity (AC:L) indicate straightforward remote exploitation. Public disclosure means exploit tooling and proof-of-concept code are likely available, accelerating threat actor adoption. The vendor's apparent non-responsiveness eliminates coordinated disclosure protections.

Remediation

Immediately contact Jinher for patches or upgrade guidance. If no official patch is available, consider blocking external access to nextselectplan.aspx via web application firewall rules or network segmentation until a fix is released. Input validation and parameterized queries should be implemented on the httpOID parameter. Organizations unable to patch should disable or isolate the affected OA deployment.

Patch guidance

Verify the latest security advisory from Jinher to confirm available patch versions and upgrade procedures. Organizations should prioritize deployment of any patch addressing CVE-2026-11435 before restoring full network access. Until patched, restrict administrative and external access to the Jinher OA instance. Test patches in a non-production environment first to ensure workflow continuity.

Detection guidance

Monitor web server and application logs for requests to nextselectplan.aspx containing suspicious SQL syntax or encoded payloads in the httpOID parameter. Look for patterns such as UNION SELECT, DROP TABLE, INSERT INTO, or encoded equivalents (e.g., %27, %3B). Implement network-level detection rules that flag anomalous SQL keywords in HTTP parameters. Database audit logs should be reviewed for unexpected query patterns or access by the OA application service account.

Why prioritize this

This vulnerability merits immediate attention due to: (1) network accessibility with no authentication required, (2) public availability of proof-of-concept code, (3) vendor non-responsiveness preventing coordinated disclosure, (4) direct database access potential, and (5) high CVSS score (7.3). Organizations should treat this as a critical remediation priority.

Risk score, explained

The CVSS v3.1 score of 7.3 (HIGH) reflects the combination of network accessibility, lack of authentication requirements, and measurable impact on data confidentiality, integrity, and availability. The score does not account for the elevated real-world risk posed by public exploit disclosure and vendor non-responsiveness; organizations should consider this vulnerability higher priority than the base CVSS alone suggests.

Frequently asked questions

What Jinher OA versions are vulnerable?

Jinher OA version 1.0 is confirmed vulnerable. Consult Jinher's security advisory to determine whether version 1.1 and later have patched this issue. If no official advisory is available, assume all versions unless proven otherwise.

Can this vulnerability be exploited without network access?

No. The CVSS vector indicates AV:N (network-accessible), meaning an attacker needs only a network route to the affected system. No local access, authentication, or physical interaction is required.

Is there a workaround if we cannot patch immediately?

While a comprehensive workaround is not a substitute for patching, you can reduce exposure by: disabling nextselectplan.aspx if not operationally required, blocking access to it at the firewall, restricting OA access to trusted internal networks only, and monitoring logs for exploitation attempts.

How should we approach patching if our vendor has not responded?

Contact Jinher through multiple channels (support, security contact, public social media) for an emergency response. In parallel, assess whether alternative OA platforms exist and develop a migration timeline. Do not delay patching decisions waiting for an unresponsive vendor; escalate to executive leadership and consider forcing an upgrade on a compressed timeline.

This analysis is based on publicly disclosed information as of the CVE publication date. Vendor response status and patch availability may change; always verify current guidance directly with Jinher. This assessment does not constitute a comprehensive penetration test or vulnerability assessment for any specific organization. Organizations should conduct their own risk analysis based on their infrastructure, business criticality, and threat model. SEC.co provides this information for informational purposes and does not guarantee the accuracy or completeness of third-party vendor disclosures. Source: NVD (public-domain), retrieved 2026-07-14. Analysis generated by SEC.co (claude-haiku-4-5).