CVE-2023-51925 is a critical arbitrary file upload flaw in the ArcpUploadAction of Yonyou YonBIP v3_23.05, scored 9.8. Uploading a crafted file leads to code execution. No distinct fixed build is confirmed, so ask Yonyou for the patch and limit who can reach the application.
What's affected
CVE-2023-51925 affects YonBIP v3_23.05 from Yonyou. NVD published it on 2024-01-20 with a score of 9.8 (critical) and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. NVD describes an arbitrary file upload in the nccloud.web.arcp.taskmonitor.action.ArcpUploadAction.doAction() method. The reporter notes say the method takes the file name from the request as the storage path and writes the file content to it, and that directory traversal is possible.
The reporter's notes list the fixed version as YonBIP v3_23.05 (patched). That is the same label as the affected version, so it does not tell you which build contains the fix. Treat the fix status as unconfirmed and ask Yonyou for the exact patched build.
Note that CVE-2023-51928 carries an identical description in NVD, but the reporter notes for that ID describe a different interface. See the guide for that CVE.
Five sibling CVEs were published against the same release on the same day: CVE-2023-51906, CVE-2023-51924, CVE-2023-51926, CVE-2023-51927, CVE-2023-51928. They are separate weaknesses in different components, so fixing one does not close the others. Ask for a patch that covers all six.
Weakness class: CWE-434.
How to check if you're exposed
Start with inventory. Find out whether you run YonBIP, and which release. The record names version 3_23.05, so any instance reporting that release is in scope until Yonyou says otherwise. Your vendor or integrator can tell you the build string from the product's admin or about page, because this is a commercial enterprise suite and I could not confirm a command-line check from the advisory.
Then check exposure. Most of the damage in this family comes from reaching the servlet endpoint over the network without logging in, so list every host that serves YonBIP and note whether it is reachable from the internet or only from an internal network. Your reverse proxy or load balancer logs show which paths receive traffic from outside.
If a web application firewall sits in front, review its logs for unexpected requests to the servlet path named in the advisory, and for new or modified files in the application's web directories. Unexpected files in those directories are the clearest sign that an upload flaw was used.
What to do now
- Confirm whether you run YonBIP v3_23.05 and record every instance, including test and staging copies.
- Contact Yonyou or your integrator and ask for the patched build and release notes for this CVE. Do not assume the label patched in the reporter notes means your build is fixed.
- Remove internet exposure. Put the application behind a VPN or an allow list of known source addresses until the patch is confirmed.
- Review web server and application logs since the product went live for requests to the affected component, and check web directories for files you did not deploy.
- If you find unexpected files, treat the host as compromised: isolate it, preserve logs, rotate credentials the application could read, and rebuild from a known good image.
Why it matters
The cause is an upload handler that trusts the client file name. When a name containing directory steps is used as a storage path, the file can land outside the intended folder. This is CWE-434, and the reporter also calls out path traversal. A server that stores attacker content in a location it will execute turns a file write into code execution.
Unauthenticated, network reachable flaws in enterprise business software are attractive because the product often holds finance, HR and supply chain data. The record's KEV flag is false, and I found no advisory stating exploitation in the wild, so this is a patch and exposure problem rather than a known active campaign.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does the record say the attacker needs to log in?
No. The vector has no privileges required and no user interaction. The reporter calls it a backstage upload issue, so check with Yonyou whether any session is needed in your build.
Why is path handling the main concern?
Because the file name chosen by the requester decides where the file is stored. Validating and fixing the storage path on the server side is the standard fix for this class.
Sources
Reporter notes for CVE-2023-51925 on GitHub (fetched, third party, not a vendor advisory)
NVD record for CVE-2023-51925 (the record this guide is built from)
Yonyou website (listed in the record; no advisory found there)
Last reviewed: 19 October 2026.
