Package Instance

Spring Framework vulnerable to Denial of Service
In Spring Framework versions 5.3.0 - 5.3.38 and older unsupported versions, it is possible for a user to provide a specially crafted Spring Expression Language (SpEL) expression that may cause a denial of service (DoS) condition. Older, unsupported versions are also affected.

Specifically, an application is vulnerable when the following is true:

  *  The application evaluates user-supplied SpEL expressions.

Jenkins exposes multi-line secrets through error messages
Jenkins 

Jenkins provides the `secretTextarea` form field for multi-line secrets.

Jenkins 2.478 and earlier, LTS 2.462.2 and earlier does not redact multi-line secret values in error messages generated for form submissions involving the `secretTextarea` form field.

This can result in exposure of multi-line secrets through those error messages, e.g., in the system log.

Jenkins 2.479, LTS 2.462.3 redacts multi-line secret values in error messages generated for form submissions involving the `secretTextarea` form field.

Improper Certificate Validation
Apache Sling Commons Messaging Mail provides a simple layer on top of JavaMail/Jakarta Mail for OSGi to send mails via SMTPS. To reduce the risk of "man in the middle" attacks additional server identity checks must be performed when accessing mail servers. For compatibility reasons these additional checks are disabled by default in JavaMail/Jakarta Mail. The SimpleMailService in Apache Sling Commons Messaging Mail 1.0 lacks an option to enable these checks for the shared mail session. A user could enable these checks nevertheless by accessing the session via the message created by SimpleMessageBuilder and setting the property mail.smtps.ssl.checkserveridentity to true. Apache Sling Commons Messaging Mail 2.0 adds support for enabling server identity checks and these checks are enabled by default. - https://javaee.github.io/javamail/docs/SSLNOTES.txt - https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html - https://github.com/eclipse-ee4j/mail/issues/429

Jenkins item creation restriction bypass vulnerability
Jenkins provides APIs for fine-grained control of item creation:

- Authorization strategies can prohibit the creation of items of a given type in a given item group (`ACL#hasCreatePermission2`).

- Item types can prohibit creation of new instances in a given item group (`TopLevelItemDescriptor#isApplicableIn(ItemGroup)`).

If an attempt is made to create an item of a prohibited type through the Jenkins CLI or the REST API and either of the above checks fail, Jenkins 2.478 and earlier, LTS 2.462.2 and earlier creates the item in memory, only deleting it from disk.

This allows attackers with Item/Create permission to bypass these restrictions, creating a temporary item. With Item/Configure permission, they can also save the item to persist it.

If an attempt is made to create an item of a prohibited type through the Jenkins CLI or the REST API and either of the above checks fail, Jenkins 2.479, LTS 2.462.3 does not retain the item in memory.