RHSA-2026:56869HighCVSS 8.1

Red Hat Security Advisory: Red Hat JBoss Core Services Apache HTTP Server 2.4.62 SP5 security update

Published
August 19, 2026
Last Modified
August 26, 2026

🔗 CVE IDs covered (30)

CVE-2026-34356 →CVE-2026-42536 →CVE-2026-8927 →CVE-2026-24072 →CVE-2026-48913 →CVE-2024-43204 →CVE-2026-3783 →CVE-2026-8286 →CVE-2026-12064 →CVE-2026-42535 →CVE-2026-43951 →CVE-2026-8932 →CVE-2026-9547 →CVE-2024-42516 →CVE-2026-1965 →CVE-2026-29170 →CVE-2026-44186 →CVE-2026-44631 →CVE-2026-6253 →CVE-2026-8924 →CVE-2026-9079 →CVE-2026-44119 →CVE-2026-44185 →CVE-2026-3784 →CVE-2026-9545 →CVE-2026-29167 →CVE-2026-8458 →CVE-2026-10536 →CVE-2026-7168 →CVE-2026-34355 →

📋 Description

CVE-2024-42516 — httpd: incomplete fix for CVE-2023-38709 CVE-2024-43204 — httpd: SSRF in Apache HTTP Server with mod_proxy loaded CVE-2026-1965 — curl: curl: Authentication bypass due to incorrect connection reuse with Negotiate authentication CVE-2026-3783 — curl: curl: Information disclosure via OAuth2 bearer token leakage during HTTP(S) redirect CVE-2026-3784 — curl: curl: Unauthorized access due to improper HTTP proxy connection reuse CVE-2026-6253 — curl: curl: Proxy credential disclosure via redirects to unauthenticated proxies CVE-2026-7168 — curl: libcurl: Information disclosure via incorrect Proxy-Authorization header reuse CVE-2026-8286 — curl: curl: Insecure connection establishment due to TLS configuration mismatch CVE-2026-8458 — curl: libcurl: Unauthorized connection reuse due to a logical error CVE-2026-8924 — curl: curl: Cookie injection via malicious HTTP server using super cookies CVE-2026-8927 — curl: Information disclosure due to uncleared proxy authentication state CVE-2026-8932 — libcurl: libcurl: Security feature bypass due to improper mTLS connection reuse CVE-2026-9079 — libcurl: libcurl: Information disclosure due to failure to clear proxy authentication credentials CVE-2026-9545 — libcurl: libcurl: Information disclosure via cached SSL session and early data CVE-2026-9547 — curl: curl: Man-in-the-middle attack via SSH host key bypass CVE-2026-10536 — libcurl: libcurl: Use-after-free vulnerability leading to Denial of Service CVE-2026-12064 — curl: curl: SSH host verification bypass when using schemeless URLs with SFTP/SCP CVE-2026-24072 — Apache HTTP Server: mod_rewrite: Apache HTTP Server: Privilege Escalation via .htaccess file manipulation CVE-2026-29167 — httpd: Apache HTTP Server: Arbitrary code execution or denial of service via use-after-free in mod_ldap per-directory configuration CVE-2026-29170 — httpd: Apache HTTP Server: Cross-site scripting in mod_proxy_ftp via HTML directory list generation CVE-2026-34355 — httpd: Apache HTTP Server: Buffer overflow in mod_proxy_html allows security bypass CVE-2026-34356 — httpd: Apache HTTP Server: Heap-based Buffer Overflow via malicious backend servers CVE-2026-42535 — httpd: Apache httpd mod_dav_fs: Denial of Service due to path handling issue CVE-2026-42536 — httpd: Apache HTTP Server: Heap-based Buffer Overflow via untrusted content in mod_xml2enc CVE-2026-43951 — httpd: Apache HTTP Server: Out-of-bounds Read in mod_headers and mod_mime CVE-2026-44119 — httpd: Apache HTTP Server: Local .htaccess authors can read files with httpd user privileges CVE-2026-44185 — httpd: Apache HTTP Server: Buffer Over-read via outbound OCSP requests to attacker-controlled server CVE-2026-44186 — httpd: Apache HTTP Server: Denial of Service in mod_proxy_ftp via attacker-controlled FTP server CVE-2026-44631 — httpd: Apache HTTP Server: Denial of Service via crafted regular expressions CVE-2026-48913 — httpd: mod_http2: Apache HTTP Server mod_http2: Use After Free vulnerability allows arbitrary code execution or denial of service.

🎯 Affected products1

  • Red Hat JBoss Core Services 2.4.62.SP5

✅ Remediation

Before applying this update, make sure all previously released errata relevant to your system have been applied. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258 Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. Workaround: No mitigation is currently available that meets Red Hat Product Security’s standards for usability, deployment, applicability, or stability. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: To prevent the leakage of OAuth2 bearer tokens, ensure that `.netrc` files are carefully managed. Avoid configuring `.netrc` entries for untrusted or unknown hostnames, particularly when `curl` is used with OAuth2 bearer tokens and is configured to follow redirects. Regularly review and restrict the scope of credentials stored in `.netrc` files to only explicitly trusted destinations. Workaround: To mitigate this issue, avoid configuring curl or libcurl to use proxies that require credentials. This prevents the scenario where credentials for a first proxy could be inadvertently passed to a second proxy during a redirect. Workaround: To mitigate this issue, applications using libcurl should avoid reusing handles when switching between different HTTP proxies, especially after performing Digest authentication. This operational control prevents the unintended disclosure of `Proxy-Authorization` headers to subsequent proxy hosts. Workaround: Do not use trailing-dot hostnames in URLs passed to curl. Trailing dots are uncommon and incompatible with TLS SNI. Upgrade to curl 8.21.0 to resolve Workaround: To mitigate this issue, applications utilizing libcurl should avoid reusing handles when switching between different proxy configurations. This operational control prevents the unintended leakage of `Proxy-Authorization` headers to incorrect proxies. Workaround: To mitigate this issue, avoid configuring HTTP/2 stream dependencies within applications utilizing libcurl. This functionality is considered deprecated and its use is required to trigger the vulnerability. Workaround: To mitigate this issue, avoid using the `--proto-default sftp` or `--proto-default scp` options with schemeless URLs when invoking the `curl` command. Instead, explicitly specify the protocol in the URL (e.g., `sftp://host/path` or `scp://host/path`). Workaround: To prevent local users from exploiting this flaw via .htaccess file manipulation, configure Apache HTTP Server to disable .htaccess overrides. Set `AllowOverride None` within the main server configuration or relevant `<Directory>` blocks. This restricts the ability of local users to alter server settings. After applying this change, the `httpd` service must be reloaded or restarted for the new configuration to take effect. Example configuration: ``` <Directory "/var/www/html"> AllowOverride None </Directory> ``` To apply changes, reload the service: `sudo systemctl reload httpd` Or restart the service: `sudo systemctl restart httpd` Workaround: upgrade apache web server to 2.4.68 Workaround: Disable the `mod_proxy_html` module if it is not essential for your Apache HTTP Server configuration. If `mod_proxy_html` is required, restrict its use to trusted backend servers only, employing network segmentation and access controls. After modifying the configuration, reload the httpd service for changes to apply, which may cause a brief service interruption. Steps to disable: Open /etc/httpd/conf.modules.d/00-proxy.conf. Add a # to comment out the line: LoadModule proxy_html_module modules/mod_proxy_html.so Verify configuration syntax: apachectl configtest Apply the change gracefully: systemctl reload httpd Workaround: To prevent this denial-of-service flaw, ensure your Apache proxy rules only connect to highly trusted backend servers. If you must proxy traffic to unverified or external backends, disable the cookie-rewriting features. Steps to Mitigate: Open your Apache configuration file (e.g., /etc/httpd/conf/httpd.conf). Locate and comment out any ProxyPassReverseCookieDomain or ProxyPassReverseCookiePath lines pointing to untrusted backends by adding a # at the start of the line. Test your syntax: apachectl configtest Apply changes gracefully: systemctl reload httpd Note: This may cause a brief service interruption. Workaround: To mitigate this vulnerability, disable the `mod_xml2enc` module if its functionality for XML internationalization is not essential. This can be done by commenting out the `LoadModule xml2enc_module modules/mod_xml2enc.so` directive in the Apache HTTP Server configuration. A service restart is required for the change to take effect. ```bash # Edit the Apache configuration file, e.g., /etc/httpd/conf.modules.d/00-base.conf # Comment out the line: # LoadModule xml2enc_module modules/mod_xml2enc.so # Reload the httpd service sudo systemctl reload httpd ``` *Note: Disabling `mod_xml2enc` will cause any configurations relying heavily on `mod_proxy_html` or raw HTML/XML encoding conversions to function incorrectly or fail. Red Hat strongly recommends upgrading to a patched version of `httpd` as soon as it becomes available for your specific RHEL channel.* Workaround: - Those who do not require multi-language response headers can remove or disable the `mod_headers` and `mod_mime` modules, or remove Content-Language directives from their configuration. - Systems not using these modules in combination are not affected. Workaround: To mitigate this issue, ensure that Apache HTTP Server is configured to only communicate with trusted OCSP responders. If OCSP validation or stapling is not a critical requirement for your deployment, consider disabling it. This can be achieved by adjusting mod_ssl directives in your Apache HTTP Server configuration. For example, add or modify the following lines: ~~~ SSLOCSPEnable off SSLUseStapling off ~~~ After modifying the configuration, reload the httpd service for the changes to take effect safely without interrupting active connections: ~~~ sudo systemctl reload httpd ~~~ Workaround: To mitigate this issue, you can disable the `mod_proxy_ftp` module if your environment does not require it. #### **Step 1: Disable the Module** Open your Apache HTTP Server configuration file (commonly located at `/etc/httpd/conf.modules.d/00-proxy.conf` or `/etc/httpd/conf/httpd.conf`) and comment out or remove the following line: ``` # LoadModule proxy_ftp_module modules/mod_proxy_ftp.so ``` #### **Step 2: Restart the Service** Restart the `httpd` service to apply the configuration changes: ``` systemctl restart httpd ``` **Note:** Disabling this module may impact applications or services that rely on Apache's FTP proxy functionality. Workaround: Only loadtrustedApache configuration; the bug triggers oncrafted regexin config at start/reload (DirectoryMatch,Directory ~,ProxyMatch, etc.). Keep AllowOverride None where possible so untrusted users cannot inject regex via .htaccess. Restrict who can change httpdconfig and reload the service. Workaround: To mitigate this issue, disable the `mod_http2` module if HTTP/2 protocol support is not required. This can be achieved by commenting out or removing the `LoadModule http2_module modules/mod_http2.so` line in the Apache HTTP Server configuration file (e.g., `/etc/httpd/conf.modules.d/00-base.conf` or similar). After modifying the configuration, the httpd service must be restarted for the changes to take effect. This action may impact services relying on HTTP/2.

🔗 References (28)