CVE-2026-34762
Inconsistent IMSI Verification in Ella Core 5G API Enables Unauthorized Policy Modification
Publication date: 2026-04-02
Last updated on: 2026-04-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| ellanetworks | ella_core | to 1.8.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-20 | The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-34762 is a vulnerability in the Ella Core 5G private network software, specifically in versions up to 1.7.0. The issue occurs in the PUT /api/v1/subscriber/{imsi} API endpoint, which accepts an IMSI identifier both from the URL path and the JSON request body but does not verify that these two IMSI values match.
Because of this lack of verification, an authenticated NetworkManager can modify any subscriber's policy by providing different IMSI values in the path and body. This causes the audit logs to record changes under a fabricated or unrelated IMSI, leading to falsified audit trails.
This vulnerability is classified as improper input validation (CWE-20) and was fixed in version 1.8.0 by removing the IMSI parameter from the request body and relying solely on the path parameter.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows an authenticated NetworkManager to modify any subscriber's policy while the audit trail records a fabricated or unrelated subscriber IMSI. This audit log falsification can undermine the integrity and reliability of audit records.
Since accurate and reliable audit trails are critical for compliance with standards and regulations such as GDPR and HIPAA, which require proper logging and traceability of data access and modifications, this vulnerability could negatively impact compliance by making forensic investigations ineffective and obscuring the true source of changes.
How can this vulnerability impact me? :
This vulnerability allows an authenticated NetworkManager to modify any subscriber's Quality of Service (QoS) policy without proper authorization checks tied to the actual subscriber IMSI.
The impact includes unauthorized changes to subscriber policies, which could degrade service quality or alter traffic routing for subscribers.
Additionally, because the audit logs record changes under incorrect IMSI values, forensic investigations after incidents become ineffective, as the true source and target of changes are obscured.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the PUT /api/v1/subscriber/{imsi} API accepting mismatched IMSI values in the URL path and JSON request body without verification. Detection would involve monitoring or inspecting API requests to identify cases where the IMSI in the URL path differs from the IMSI in the JSON body.
Since the vulnerability requires authenticated access and involves API request content, detection can be done by logging and analyzing API calls to the PUT /api/v1/subscriber/{imsi} endpoint, checking for discrepancies between the IMSI in the URL and the IMSI in the request body.
- Use network traffic capture tools (e.g., tcpdump, Wireshark) to capture HTTP PUT requests to /api/v1/subscriber/* and inspect the IMSI values in the URL and JSON body.
- Use command-line tools like curl or httpie with authentication to manually test the endpoint by sending PUT requests with differing IMSI values in the URL and body to see if the system accepts them.
- Example curl command to test the vulnerability (requires valid authentication token):
curl -X PUT "https://<server>/api/v1/subscriber/123456789012345" -H "Authorization: Bearer <token>" -H "Content-Type: application/json" -d '{"imsi":"987654321098765", "policy": {"qos": "high"}}'
If the request succeeds and the system accepts the differing IMSI values, the vulnerability is present.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability has been fixed in Ella Core version 1.8.0 by removing the IMSI parameter from the request body and relying solely on the IMSI in the URL path.
Immediate mitigation steps include:
- Upgrade Ella Core to version 1.8.0 or later where the vulnerability is patched.
- Restrict access to the PUT /api/v1/subscriber/{imsi} API endpoint to only trusted and authenticated NetworkManager or Admin users.
- Implement monitoring and alerting for suspicious API requests where the IMSI in the URL and body do not match.
- Review audit logs for any signs of unauthorized subscriber policy modifications and verify IMSI consistency.