An arbitrary file write vulnerability was found in GNU gzip's zgrep utility. When zgrep is applied on the attacker's chosen file name (for example, a crafted file name), this can overwrite an attacker's content to an arbitrary attacker-selected file. This flaw occurs due to insufficient validation when processing filenames with two or more newlines where selected content and the target file names are embedded in crafted multi-line file names. This flaw allows a remote, low privileged attacker to force zgrep to write arbitrary files on the system.
Apache CXF could allow a remote attacker to obtain sensitive information, caused by a flaw when ships with OpenId Connect JWK Keys service. By accessing the JWK keystore file, an attacker could exploit this vulnerability to obtain the public keys in JWK format, and use this information to launch further attacks against the affected system.
A flaw was found in the way Apache CXF handle exceptions when CXF is configured to use the com.sun.net.ssl implementation via System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol") function. When this system property is set, CXF uses some reflection to try to make the HostnameVerifier work with the old com.sun.net.ssl.HostnameVerifier interface. However, the default HostnameVerifier implementation in CXF does not implement the method in this interface therefore an exception is thrown. The exception is caught in the reflection code but not properly propagated which leaves CXF client subject to man-in-the-middle attacks.
Upstream Patch: https://github.com/apache/cxf/commit/fae6fabf9bd7647f5e9cb68897a7d7
A vulnerability in the JsonMapObjectReaderWriter of Apache CXF allows an attacker to submit malformed JSON to a web service, which results in the thread getting stuck in an infinite loop, consuming CPU indefinitely. This issue affects Apache CXF versions prior to 3.4.4; Apache CXF versions prior to 3.3.11.
Apache CXF is vulnerable to a denial of service, caused by improper validation of requesturi parameter by the OAuth 2 authorization service. By sending a specially-crafted request, a remote attacker could exploit this vulnerability to cause a denial of service condition on the authorization server.
A out-of-bounds write flaw was found in the xorg-x11-server. This issue occurs due to an incorrect calculation of a buffer offset when copying data stored in the heap in the XIChangeDeviceProperty function in Xi/xiproperty.c and in RRChangeOutputProperty function in randr/rrproperty.c, allowing for possible escalation of privileges or denial of service.
A heap-based buffer overflow was found in the way sudo parses command line arguments.
As per the researcher this vulnerability:
- is exploitable by any local user (normal users and system users, sudoers and non-sudoers), without authentication (i.e., the attacker does not need to know the user's password);
- was introduced in July 2011 (commit 8255ed69), and affects all legacy versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to 1.9.5p1, in their default configuration.
This could lead to privilege escalation.
An issue was discovered in Squid before 4.10. Due to incorrect input validation, it can interpret crafted HTTP requests in unexpected ways to access server resources prohibited by earlier security filters.
An issue was discovered in Squid before 4.10. Due to incorrect buffer management, a remote client can cause a buffer overflow in a Squid instance acting as a reverse proxy.
GNOME libxml2 is vulnerable to a denial of service, caused by an error in xmlStringLenDecodeEntities in parser.c. An attacker could exploit this vulnerability to cause the application to enter into an infinite loop.
Last updated 25 August 2025
An issue was discovered in Squid before 4.10. It allows a crafted FTP server to trigger disclosure of sensitive information from heap memory, such as information associated with other users' sessions or non-Squid processes.
A flaw was found in PostgreSQL that allows authenticated database users to execute arbitrary code through missing overflow checks during SQL array value modification. This issue exists due to an integer overflow during array modification where a remote user can trigger the overflow by providing specially crafted data. This enables the execution of arbitrary code on the target system, allowing users to write arbitrary bytes to memory and extensively read the server's memory.
A memory leak was found in the xmlSchemaValidateStream function of libxml2. Applications that use this library may be vulnerable to memory not being freed leading to a denial of service. System availability is the highest threat from this vulnerability.
Mozilla Firefox could allow a remote attacker to obtain sensitive information, caused by an out-of-bounds read when importing a curve25519 private key in PKCS#8format. By persuading a victim to visit a specially-crafted Web site, a remote attacker could exploit this vulnerability using unknown attack vectors to obtain sensitive information.
A flaw was found in rsyslog's reception TCP modules. This flaw allows an attacker to craft a malicious message leading to a heap-based buffer overflow. This issue allows the attacker to corrupt or access data stored in memory, leading to a denial of service in the rsyslog or possible remote code execution.
A flaw stack overflow in the Linux Kernel found. If user have access to SYSCTL (dynamically changing certain kernel parameters and variables), then can provide incorrect input to the function doprocdointvec leading to system crash or potentially privileges escalation. Known example of such incorrect input by local user for the /proc/sys/net/ipv4/tcprmem , but it could be other situations when this function being used.
References: https://seclists.org/oss-sec/2022/q4/178 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-procskipspaces-shouldn-t-think-it-is-working-on-c-strings.patch https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-avoid-integer-type-confusion-in-getproclong.patch
IBM Security Guardium 11.3, 11.4, and 11.5 could allow a local user to obtain elevated privileges due to incorrect authorization checks. IBM X-Force ID: 216753.
Last updated 25 August 2025
A flaw was found in the Linux kernel’s multi-touch input system. An out-of-bounds write triggered by a use-after-free issue could lead to memory corruption or possible privilege escalation. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.
A flaw was discovered in ibus in versions before 1.5.22 that allows any unprivileged user to monitor and send method calls to the ibus bus of another user due to a misconfiguration in the DBus server setup. A local attacker may use this flaw to intercept all keystrokes of a victim user who is using the graphical interface, change the input method engine, or modify other input related configurations of the victim user.
IBM Security Guardium 11.2 is vulnerable to SQL injection. A remote attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify or delete information in the back-end database. IBM X-Force ID: 192710.
IBM Security Guardium 10.5 and 11.3 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt sensitive information. IBM X-Force ID: 215585.
IBM Security Guardium 10.6 and 11.2 could allow a local attacker to execute arbitrary commands on the system as an unprivileged user, caused by command injection vulnerability. IBM X-Force ID: 186700.
IBM Security Guardium 11.2 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 196280.
Impact
When using --userns-remap, if the root user in the remapped namespace has access to the host filesystem they can modify files under /var/lib/docker/<remapping> that cause writing files with extended privileges.
Patches
Versions 20.10.3 and 19.03.15 contain patches that prevent privilege escalation from remapped user.
Credits
Maintainers would like to thank Alex Chapman for discovering the vulnerability; @awprice, @nathanburrell, @raulgomis, @chris-walz, @erin-jensby, @bassmatt, @mark-adams, @dbaxa for working on it and Zac Ellis for responsibly disclosing it to security@docker.com