CVE-2024-0510 is a high severity (7.3) server side request forgery in YiQiNiu. It affects HaoKeKeJi YiQiNiu up to version 3.1. The record names no fixed version. Treat the product as exposed until you confirm the version and restrict who can reach it.
What's affected
- Product and location: HaoKeKeJi YiQiNiu up to version 3.1, in the http_post function of /application/pay/controller/Api.php.
- The vulnerable parameter is url. The record says the attack may be launched remotely and an exploit is public.
- Fixed version: The record names no fixed version.
- Severity: NVD scores it 7.3 (High), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. The disclosure text calls the issue critical, while the NVD score is high. Both figures are shown so you can judge for yourself.
- Published: 2024-01-13.
- The record says the exploit has been disclosed to the public and may be used.
How to check if you're exposed
- Find the deployed application and read its version from the project files.
- Check the outbound firewall rules for the application host.
- Review application and proxy logs for requests to internal addresses that the payment or API feature should never contact.
Keep a record of what you find. An inventory that lists the product, version and owner turns the next advisory into a lookup instead of a search. Safeguard's dependency scan runs in the browser for the software you build.
What to do now
- Confirm whether you run the product and which version, using the checks above.
- Look for a vendor update. If none exists, assume the product stays unpatched.
- Block outbound requests from the application host to internal ranges unless they are needed.
- Validate any user supplied URL against an allow list of hosts.
- Log outbound requests from the application so odd destinations stand out.
- Run the free dependency scan at gold.safeguard.sh/scan on projects of yours that bundle similar components, and look the CVE up in the Gold directory.
Why it matters
The weakness is CWE-918, server side request forgery. The application accepts a URL from the caller and makes a request to it from the server. The server can then be pointed at addresses the caller could not reach directly, such as internal services.
Defenders usually care most about what the server can reach: cloud metadata endpoints, admin panels on private networks and internal APIs. Limiting outbound traffic from the web tier reduces the damage even when a code flaw exists.
The record lists CWE-918 for this CVE and carries no CISA Known Exploited Vulnerabilities flag. The scores in this post come from NVD and may be revised.
Try it yourself
The demo below walks through the same workflow on sample data.
Click through it at your own pace, or open it full screen.
Quick check
Why does SSRF matter if the app itself holds no secrets?
Because the request originates inside your network. It can touch services that trust internal callers, so the exposure is often larger than the vulnerable application suggests.
Sources
I did not fetch the pages below, so every statement here comes from the NVD record. The VulDB entry and researcher write ups were not independently confirmed.
- https://note.zhaoj.in/share/gBtNhBb39u9u
- https://vuldb.com/?ctiid.250652
- https://vuldb.com/?id.250652
Last reviewed: 19 October 2026.
