CVE-2026-82815 is a high severity (CVSS 7.3) improper access control flaw in MegaEase EaseProbe up to 2.3.0. The realIP function in web/server.go trusts client IP headers, so a remote caller can influence access decisions. No fixed version is confirmed and the vendor did not respond.
What's affected
The record lists MegaEase EaseProbe up to 2.3.0. The function is realIP in web/server.go, part of the web server middleware. It reads the client address from the X-Forwarded-For, X-Real-IP and True-Client-IP headers. Those headers are set by the caller unless a trusted proxy overwrites them, so a remote client can supply any address it likes.
The record says the vendor was contacted early and did not respond, and that an exploit has been published. It names no fixed version. I could not retrieve the VulDB entries or the researcher's repository, so I have no second source on severity or versions. Treat the fix status as unknown and check the EaseProbe releases page for anything newer than 2.3.0.
The record calls the exploit published, which is not the same as exploitation in the wild. It is not on the CISA list.
How to check if you're exposed
Find the EaseProbe version you run. Look at the release or image tag you deployed, and check your Kubernetes manifests, compose files or install scripts for the version. Then answer the question that decides your exposure: does the EaseProbe web server sit behind a proxy that overwrites the forwarding headers, and does anything in your setup use the client address for access decisions such as an allow list?
If the web interface is only reachable from a private network with no address based rules, the weakness has little to work with. If it faces the internet, assume anyone can send a forged header and act on that.
What to do now
- Find every EaseProbe instance and record its version. Anything at 2.3.0 or below is in scope.
- Check the project's releases and issue tracker for a fix, because none is confirmed in the record.
- Put the web interface behind a proxy that strips incoming forwarding headers and sets its own, or remove public access entirely.
- Do not rely on client IP allow lists for the EaseProbe interface. Use real authentication in front of it.
- Add EaseProbe to your dependency inventory so a future fixed release is flagged when it ships.
Why it matters
Improper access control, tracked as CWE-284, and the related privilege handling weakness CWE-266 describe a system that makes an access decision on data the caller controls. Client address headers are the classic example. They are meant to be written by a proxy that you trust. A server that reads them directly, with nobody overwriting them, believes whatever the caller says.
The practical risk depends on what the address gates. For a monitoring tool, that may include its status pages or administrative endpoints. With no vendor response, the safest course is to take away the reason the header matters: add authentication and a proxy that normalizes headers.
Quick check
Is there a patched version?
None is confirmed in the record, and the vendor did not respond. Check the project's releases page before assuming one exists.
Is this exploited in the wild?
The record says an exploit has been published. It does not say it is being used in attacks, and it is not flagged by CISA.
Sources
- VulDB entry for CVE-2026-82815 (listed in the record; blocked when fetched)
- Researcher write-up (listed in the record)
Last reviewed: 18 October 2026.
