CVE-2026-73198: Ipa: freeipa: unauthenticated dos in `/ipa/i18n_messages` via unbounded request body read
A flaw was found in FreeIPA. A remote, unauthenticated attacker can exploit a vulnerability in the /ipa/i18nmessages endpoint by sending an arbitrarily large request body. This can cause the service to consume excessive memory, leading to memory exhaustion, degraded responsiveness, and a denial of service (DoS) condition.
Other sources
AIONLYREPORT package: ipa-4.13.1-3.el10 ------ Summary: Unauthenticated DoS in /ipa/i18nmessages via Unbounded Request Body Read: the public i18n endpoint reads attacker-controlled request bodies into memory without a size limit before rejecting invalid commands, allowing remote unauthenticated memory exhaustion and service degradation. Requirements to exploit: Network reachability to /ipa/i18nmessages and the ability to send large POST bodies. Authentication is not required. Exploitability and impact are reduced if Apache, modwsgi, or an upstream proxy already enforces a strict request-body limit. Component affected: ipa-4.13.1-3.el10 in ipaserver/rpcserver.py (readinput(), jsonserveri18nmessages.call()), with public exposure from install/share/ipa.conf.template Version affected: ipa-4.13.1-3.el10 Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 7.5 (HIGH) AV:N - The vulnerable endpoint is exposed over HTTPS and is reachable remotely. AC:L - The attack only requires oversized POST requests; no special timing, race, or bypass is needed. PR:N - The shipped Apache configuration grants unauthenticated access to /ipa/i18nmessages. UI:N - No user interaction is required. S:U - The impact is confined to the same service scope. C:N - No confidentiality impact is established by the available evidence. I:N - No integrity impact is established by the available evidence. A:H - Large or concurrent requests can drive substantial memory growth, worker churn, and potential service unavailability. Impact: Important. This is a remote, unauthenticated denial-of-service condition on a shipped public endpoint. That aligns with Red Hat's Important rating for flaws that allow remote users to cause denial of service. Critical is not appropriate because there is no evidence of code execution, privilege escalation, or confidentiality/integrity impact. Deployments that already enforce request-body limits may see reduced impact, but that mitigation is not shown in the provided package configuration. Embargo: yes Reason: The issue is remotely reachable without authentication on a default public IPA endpoint and can be exercised with commodity tools to disrupt service availability before a fix or mitigation guidance is deployed. Acknowledgement: Aisle Research Vulnerability Details: The request body helper trusts CONTENTLENGTH and reads that many bytes from wsgi.input without a size cap: python def readinput(environ): """ Read the request body from environ['wsgi.input']. """ try: length = int(environ.get('CONTENTLENGTH')) except (ValueError, TypeError): return None return environ['wsgi.input'].read(length).decode('utf-8') The unauthenticated i18n endpoint performs this read before it verifies that the RPC method is actually i18nmessages: python def call(self, environ, startresponse): logger.debug('WSGI jsonserveri18nmessages.call:') if environ['REQUESTMETHOD'] != 'POST': return self.notallowed(startresponse) data = readinput(environ) unmarshaldata = super(jsonserveri18nmessages, self ).unmarshal(data) name = unmarshaldata[0] if unmarshaldata else '' if name != 'i18nmessages': return self.forbidden(startresponse) environ['wsgi.input'] = BytesIO(data.encode('utf-8')) response = super(jsonserveri18nmessages, self ).call(environ, startresponse) return response The shipped Apache template exposes this path without authentication: apache <Location "/ipa/i18nmessages"> Require all granted </Location> As a result, a remote client can force the service to allocate memory for arbitrarily large request bodies before command validation occurs. When the method name passes validation, the body is encoded again into BytesIO, which can add another in-memory copy. The available package configuration does not show a LimitRequestBody or similar request-body cap for IPA endpoints. The demonstrated impact is denial of service through memory pressure, degraded responsiveness, worker churn, and possible OOM conditions under sustained load. No confidentiality or integrity impact is established from the available evidence. Steps to reproduce: 1. Deploy ipa-4.13.1-3.el10 with the shipped Apache configuration that exposes /ipa/i18nmessages. 2. Generate a large JSON request body, for example a 64 MiB method field: bash python3 - <<'PY' import json s = "A" (64 1024 1024) obj = {"method": s, "params":[[], {"version":"2.0"}], "id": 1} open("/tmp/ipa-big.json", "w").write(json.dumps(obj)) PY 3. Send an unauthenticated POST request to the public endpoint: bash curl -k -sS -o /dev/null -X POST \ -H 'Content-Type: application/json' \ --data-binary @/tmp/ipa-big.json \ https://<ipa-host>/ipa/i18nmessages 4. Repeat the request concurrently, for example with 10-50 workers, while monitoring httpd or modwsgi RSS with tools such as ps, top, or smem. 5. Observe memory growth and service degradation, including slow responses, worker churn or restarts, and possible OOM under sustained pressure. Mitigation: Until a code fix is available, enforce a request-body limit for /ipa/i18nmessages or /ipa/ using Apache LimitRequestBody, and apply an equivalent body-size limit in any reverse proxy or load balancer in front of IPA. This reduces or blocks oversized requests before they are read into the WSGI process. Proposed Fix: Add a hard request-body cap in readinput() and return HTTP 413 from jsonserveri18nmessages when the body is too large. diff diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py @@ +MAXREQUESTBODYSIZE = 1024 1024 # 1 MiB + def readinput(environ): """ Read the request body from environ['wsgi.input']. """ try: length = int(environ.get('CONTENTLENGTH')) except (ValueError, TypeError): return None + if length < 0 or length > MAXREQUESTBODYSIZE: + return None return environ['wsgi.input'].read(length).decode('utf-8') @@ class jsonserveri18nmessages(jsonserver): def call(self, environ, startresponse): logger.debug('WSGI jsonserveri18nmessages.call:') if environ['REQUESTMETHOD'] != 'POST': return self.notallowed(startresponse) data = readinput(environ) + if data is None: + startresponse('413 Payload Too Large', + [('Content-Type', 'text/plain; charset=utf-8')]) + return [b'Request body too large'] unmarshaldata = super(jsonserveri18nmessages, self ).unmarshal(data) ------ This report was generated using AI technology. Always review AI-generated content prior to use
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Implement a hard request-body cap in `read_input()` for `jsonserver_i18n_messages` by defining `MAX_REQUEST_BODY_SIZE = 1024 * 1024` and rejecting requests when `length < 0 or length > MAX_REQUEST_BODY_SIZE` (return HTTP 413 Payload Too Large).
FreeIPA (ipaserver/rpcserver.py) jsonserver_i18n_messages.read_input() MAX_REQUEST_BODY_SIZE = 1048576 - Compensating control
Enforce a request-body size limit for Apache access to the public IPA i18n endpoint by using Apache `LimitRequestBody` for `/ipa/i18n_messages` (and `/ipa/*` as appropriate), so oversized requests are rejected before IPA reads the request body.
Event History
Frequently Asked Questions
Who is exposed to this issue?
FreeIPA deployments where an attacker can reach the public /ipa/i18n_messages endpoint are exposed. The affected component is ipa-4.13.1-3.el10, and authentication is not required.
What does an attacker need to exploit it?
An attacker needs network reachability to /ipa/i18n_messages and the ability to send large POST request bodies. No credentials or user interaction are required.
Are deployments protected by request-size limits still affected?
Apache, mod_wsgi, or an upstream proxy that already enforces a strict request-body limit reduces exploitability and impact. Without such a limit, the endpoint can read an attacker-controlled body into memory before rejecting invalid commands.
What can be done while no released package patch is available?
Enforce a strict request-body size limit in Apache, mod_wsgi, or an upstream proxy for requests to /ipa/i18n_messages. Restricting network access to that endpoint can also reduce exposure where feasible.