CVE-2025-10410 is a medium severity flaw in SourceCodester Link Status Checker 1.0, scored 6.3 by NVD. It allows server-side request forgery through the proxy argument of index.php. The record lists no fixed version, so restrict access to the affected page, review the code, and check the vendor for a patch.
What's affected
The record names SourceCodester Link Status Checker 1.0. The affected code is in index.php. The vulnerable input is the proxy parameter.
No fixed version appears in the record or in the reference pages I could read. Do not assume a later release is safe. Check the vendor or project page for a patched release, and if none exists, plan on mitigation or replacement.
The record says the exploit has been published and may be used. It does not say the flaw is exploited in the wild, and it is not on the CISA Known Exploited Vulnerabilities list.
How to check if you're exposed
First confirm the product and version: SourceCodester Link Status Checker 1.0. Applications like this are usually installed by copying source files to a server, so no package manager records them and a dependency scan may not list them. Gold's free in-browser dependency scan still covers the libraries that sit next to them, and your own asset list is the place to find the application itself.
Then check what the server can reach. The risk with server-side request forgery is the network around the server, so list what is on the same host and network that should never be fetched from the web: admin ports, internal dashboards and cloud metadata addresses.
Read the code that handles the proxy value in index.php. If it fetches whatever address it is given, with no allow list and no block on private ranges, the application is affected. Your egress logs also help. Look for requests from the web server to internal addresses that it has no reason to contact.
What to do now
- Find every copy of the application and decide whether it still needs to run.
- Check for a newer release. The record shows none, and for some reports the vendor did not respond.
- Put the application behind authentication if it is not already, and take it off the public internet where you can.
- Block outbound requests from the web server to private ranges, loopback and cloud metadata addresses at the host or network firewall.
- In the code, allow only http and https, resolve the host name yourself, reject private and link local addresses, and do not follow redirects blindly.
- Review egress logs for fetches from the server to internal addresses.
Why it matters
This is server-side request forgery, listed under CWE-918 (server-side request forgery). The server is asked to fetch a web address chosen by the visitor, and it does so from inside your network. That lets an outsider use the server as a proxy to reach things that are not exposed to the internet, such as internal services and, in the cloud, metadata endpoints that hand out credentials.
The rating of 6.3 is moderate because the immediate result depends on what the server can reach. That is exactly why egress rules matter. The same application on a flat network is a bigger problem than on a locked down one.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is SSRF rated medium here?
The direct impact depends on what the server can reach. On a locked down network it is limited. On a flat network or in a cloud account with metadata access it can be much worse.
What is the best single control?
Restrict outbound traffic from the web server so it cannot reach internal ranges or metadata addresses, and validate the address in code.
Sources
Last reviewed: 19 October 2026.
