Where
AND
AND
-Infinity
0
Severity
9
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

A flaw was found in sudo before version 1.8.28. When sudo is configured to allow a user to run commands as an arbitrary user via the 'ALL' keyword in a 'Runas' specification, it is possible to run commands as root.

1 / 4
Source: Red Hat

Remedy

This vulnerability only affects configurations of sudo that have a runas user list that includes an exclusion of root. The most simple example is: ~~~ someuser ALL=(ALL, !root) /usr/bin/somecommand ~~~ The exclusion is specified using an excalamation mark (!). In this example, the "root" user is specified by name. The root user may also be identified in other ways, such as by user id: ~~~ someuser ALL=(ALL, !#0) /usr/bin/somecommand ~~~ or by reference to a runas alias: ~~~ Runas_Alias MYGROUP = root, adminuser someuser ALL=(ALL, !MYGROUP) /usr/bin/somecommand ~~~ To ensure your sudoers configuration is not affected by this vulnerability, we recommend examining each sudoers entry that includes the `!` character in the runas specification, to ensure that the root user is not among the exclusions. These can be found in the /etc/sudoers file or files under /etc/sudoers.d.
First published (updated )
Severity
9.8
Buffer Overflow
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Last updated 25 August 2025

1 / 3
Source: Ubuntu
First published (updated )
Severity
9.1
Input Validation, Infoleak
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

apache. Multiple issues were addressed by updating to version 2.4.27.

1 / 3
First published (updated )
Severity
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

apache. Multiple issues were addressed by updating to version 2.4.27.

1 / 3
First published (updated )
Severity
9.8
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

It was discovered that the RMI (Java Remote Method Invocation) server implementation in the JMX (Java Management Extensions) component of OpenJDK did not restrict which classes can be deserialized when deserializing authentication credentials. A remote unauthenticated attacker able to connect to a JMX port could possibly use this flaw trigger deserialization flaws.

1 / 5
Source: Red Hat
First published (updated )
Severity
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

It was discovered that OpenSSH client did not correctly handle situations when untrusted X11 forwarding was requested and generation of the untrusted authentication cookie failed. The ssh client continued by generating fake authentication cookie and allowed remote X clients to connect the local X server. The decision if client connection was accepted was delegated to the X server which, depending on its configuration, could allow clients to open trusted X connection. This would lead to remote X clients having more privileged access to the local X server than intended.

This problem can occur when X server does not include or enable X Security extension (for X.org X server, this extension is not compiled in by default since 2007) and when it has authentication methods besides MIT cookies enabled (e.g. localuser authentication allowing all X connections from a local user who owns the X session).

Both of these conditions are satisfied on Red Hat Enterprise Linux 7 and current Fedora versions. The X server does not have X Security extension compiled in and 'xhost +si:localuser:id -un' is run from the xinit scripts. Therefore remote X clients are granted trusted access to the local X server when 'ssh -X' is used, as if 'ssh -Y' was actually used.

The X server on Red Hat Enterprise Linux 6 includes X Security extension (as of RHSA-2013:1620 - http://rhn.redhat.com/errata/RHSA-2013-1620.html - which was released as part of Red Hat Enterprise Linux 6.5) and hence does not fall back to the use of fake authentication cookie.

This issue was corrected upstream in version 7.1p2:

http://www.openssh.com/txt/release-7.1p2

Upstream commit:

https://anongit.mindrot.org/openssh.git/commit/?id=ed4ce82dbfa8a3a3c8ea6fa0db113c71e234416c

which needs to be applied after:

https://anongit.mindrot.org/openssh.git/commit/?id=f98a09cacff7baad8748c9aa217afd155a4d493f

1 / 3
Source: Red Hat
First published (updated )

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