CVE-2025-7823 is a high severity (CVSS 7.3) XML external entity (XXE) flaw in Jinher OA 1.2. The ProjectScheduleDelete.aspx page processes XML in a way that allows external entity references, and it is reachable over the network. The record lists no fixed version, so restrict access and ask the vendor for a patch.
The description says the exploit has been disclosed to the public and may be used. The record does not mark this CVE as exploited in the wild, and it is not a CISA Known Exploited Vulnerability.
What's affected
The record lists Jinher OA 1.2, a web based office automation product, and names the file ProjectScheduleDelete.aspx. The report linked from the record spells the product Jinhe OA, so search for both spellings when you check your estate.
The same reporter filed a sibling issue against another page and version, CVE-2025-7824. It affects a different file in a different version, which suggests more than one page in the product parses XML unsafely. Do not assume that a fix for one page covers the other.
I could not confirm any fixed version. The record lists none and there is no vendor advisory among the references. Check with the vendor for a patch and for the supported version range.
Severity needs a note. The description calls the issue problematic, which is VulDB's wording. The score in the record is CVSS 7.3, High, with a vector of network access, low complexity, no privileges and no user interaction, and low impact on each of confidentiality, integrity and availability. This post uses the score.
How to check if you're exposed
Confirm which version you run. The product's about or admin page normally shows it. A match on 1.2 with the file present means you are in scope. On a Windows server running IIS, look for the page on disk:
Get-ChildItem -Path C:\inetpub -Recurse -Filter "ProjectScheduleDelete.aspx" -ErrorAction SilentlyContinue
Then check how widely the application is reachable. An office automation system should sit behind a VPN or a reverse proxy with authentication, and should not answer to anyone on the internet.
Look in the IIS logs for requests to the page from addresses you do not recognise, and for unusually large or odd requests. Outbound connections from the web server to unexpected hosts are also worth checking, because XXE flaws can make a server fetch resources on an attacker's behalf.
Safeguard's free in-browser dependency scan covers third party packages. It will not flag this issue, which sits in the application's own code, so use code review or a SAST tool for that part.
What to do now
- Find every Jinher OA or Jinhe OA deployment you run and note its version.
- Remove the product from the public internet. Put it behind a VPN or an allow list.
- Ask the vendor for a patched build and for confirmation of which pages were fixed. Keep the answer on file.
- Where you control the code or can add a rule at the proxy, block access to ProjectScheduleDelete.aspx for users who do not need it.
- Limit outbound traffic from the application server to the hosts it really needs. That cuts what an entity reference can reach.
- Review logs for the page and rotate any credentials or secrets stored on the server if you see suspicious access.
If you maintain .NET code that parses XML, the general fix is to prohibit document type definitions and turn off external resolvers on the parser. In current .NET that means setting DtdProcessing to Prohibit on XmlReaderSettings and leaving XmlResolver unset.
Why it matters
CWE-611 is improper restriction of XML external entity reference, and CWE-610 is the wider class of externally controlled references. An XML document can declare entities that point to files or network addresses. If the parser resolves them, a request can make the server read local files or contact internal systems, and the content can come back in a response or an error.
The weakness is in parser configuration, not in the business logic. It is a one line setting that is often left at an unsafe default in older code. Old office systems are especially exposed because they handle XML in several places, and each one has to be fixed on its own.
Quick check
Is Jinher OA the same as Jinhe OA?
The record uses Jinher and the public report uses Jinhe. They appear to describe the same product, so search for both names.
Does one patch cover both Jinher OA XXE CVEs?
Not necessarily. They name different files and versions. Ask the vendor which pages each build fixes.
Sources
Last reviewed: 18 October 2026.
