deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-q35w-85pq-rv3x
Package: fish.payara.distributions:payara (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-552: Files or Directories Accessible to External Parties
Vulnerable versions: >= 5.0.0.Alpha1, < 5.2022.2
Patched in: 5.2022.5

Summary: Payara, when deployed to the root context, allows attackers to visit META-INF and WEB-INF

Details:
Payara before 2022-11-04, when deployed to the root context, allows attackers to visit META-INF and WEB-INF, a different vulnerability than CVE-2022-37422. This affects Payara Platform Community before 4.1.2.191.38, 5.x before 5.2022.4, and 6.x before 6.2022.1, and Payara Platform Enterprise before 5.45.0.
GitHub Security Advisory: GHSA-q35w-85pq-rv3x
Package: fish.payara.distributions:payara (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-552: Files or Directories Accessible to External Parties
Vulnerable versions: >= 6.2021.1.Alpha1, < 6.2022.2
Patched in: 6.2022.2

Summary: Payara, when deployed to the root context, allows attackers to visit META-INF and WEB-INF

Details:
Payara before 2022-11-04, when deployed to the root context, allows attackers to visit META-INF and WEB-INF, a different vulnerability than CVE-2022-37422. This affects Payara Platform Community before 4.1.2.191.38, 5.x before 5.2022.4, and 6.x before 6.2022.1, and Payara Platform Enterprise before 5.45.0.
GitHub Security Advisory: GHSA-fghv-69vj-qj49
Package: io.netty:netty-codec-http (MAVEN)
Severity: LOW (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: >= 4.2.0.Alpha1, < 4.2.5.Final
Patched in: 4.2.5.Final

Summary: Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions

Details:
## Summary
A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.

## Details
When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)).

This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):

```
POST /one HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked

48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0

POST /two HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked

0

```

The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)).

## Impact
This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.

The impact is high, but it only affects setups that use a front-end which:
1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension.
2. Forwards chunk extensions without normalization.

## Disclosure

 - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html

## Discussion
Discussion for this vulnerability can be found here:
 - https://github.com/netty/netty/issues/15522
 - https://github.com/JLLeitschuh/unCVEed/issues/1

## Credit

 - Credit to @JeppW for uncovering this vulnerability.
 - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure.
GitHub Security Advisory: GHSA-fghv-69vj-qj49
Package: io.netty:netty-codec-http (MAVEN)
Severity: LOW (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: < 4.1.125.Final
Patched in: 4.1.125.Final

Summary: Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions

Details:
## Summary
A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.

## Details
When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)).

This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):

```
POST /one HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked

48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0

POST /two HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked

0

```

The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)).

## Impact
This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.

The impact is high, but it only affects setups that use a front-end which:
1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension.
2. Forwards chunk extensions without normalization.

## Disclosure

 - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html

## Discussion
Discussion for this vulnerability can be found here:
 - https://github.com/netty/netty/issues/15522
 - https://github.com/JLLeitschuh/unCVEed/issues/1

## Credit

 - Credit to @JeppW for uncovering this vulnerability.
 - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure.
GitHub Security Advisory: GHSA-j4fw-4mhr-hc45
Package: com.liferay:com.liferay.portal.workflow.kaleo.forms.web (MAVEN)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 5.0.29
Patched in: 5.0.29

Summary: Liferay Portal Vulnerable to Denial of Service in Kaleo Forms Admin

Details:
Kaleo Forms Admin in Liferay Portal 7.0.0 through 7.4.3.4, and Liferay DXP 7.4 GA, 7.3 GA through update 27, and older unsupported versions does not restrict the saving of request parameters in the portlet session, which allows remote attackers to consume system memory leading to denial-of-service (DoS) conditions via crafted HTTP request.
GitHub Security Advisory: GHSA-c7v7-rqfm-f44j
Package: com.vaadin:vaadin (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 24.0.0, <= 24.7.6
Patched in: 24.7.7

Summary: Vaadin Platform possible file bypass via upload validation on the server-side

Details:
### Description
When the Vaadin Upload's start listener is used to validate metadata about an incoming upload, it is possible to bypass the upload validation. Users of affected versions should apply the upgrade to a more recent Vaadin version.
GitHub Security Advisory: GHSA-c7v7-rqfm-f44j
Package: com.vaadin:vaadin (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 23.0.0, <= 23.6.1
Patched in: 23.6.2

Summary: Vaadin Platform possible file bypass via upload validation on the server-side

Details:
### Description
When the Vaadin Upload's start listener is used to validate metadata about an incoming upload, it is possible to bypass the upload validation. Users of affected versions should apply the upgrade to a more recent Vaadin version.
GitHub Security Advisory: GHSA-c7v7-rqfm-f44j
Package: com.vaadin:vaadin (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 14.0.0, <= 14.13.0
Patched in: 14.13.1

Summary: Vaadin Platform possible file bypass via upload validation on the server-side

Details:
### Description
When the Vaadin Upload's start listener is used to validate metadata about an incoming upload, it is possible to bypass the upload validation. Users of affected versions should apply the upgrade to a more recent Vaadin version.
GitHub Security Advisory: GHSA-94g8-xv23-7656
Package: com.vaadin:vaadin-upload-flow (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 24.0.0, <= 24.7.6
Patched in: 24.7.7

Summary: Vaadin Flow Components possible file bypass via upload validation on the server-side

Details:
### Description
When the Vaadin Upload's start listener is used to validate metadata about an incoming upload, it is possible to bypass the upload validation. Users of affected versions should apply the upgrade to a more recent Vaadin version.
GitHub Security Advisory: GHSA-94g8-xv23-7656
Package: com.vaadin:vaadin-upload-flow (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 23.0.0, <= 23.6.1
Patched in: 23.6.2

Summary: Vaadin Flow Components possible file bypass via upload validation on the server-side

Details:
### Description
When the Vaadin Upload's start listener is used to validate metadata about an incoming upload, it is possible to bypass the upload validation. Users of affected versions should apply the upgrade to a more recent Vaadin version.
GitHub Security Advisory: GHSA-94g8-xv23-7656
Package: com.vaadin:vaadin-upload-flow (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 2.0.0, <= 14.13.0
Patched in: 14.13.1

Summary: Vaadin Flow Components possible file bypass via upload validation on the server-side

Details:
### Description
When the Vaadin Upload's start listener is used to validate metadata about an incoming upload, it is possible to bypass the upload validation. Users of affected versions should apply the upgrade to a more recent Vaadin version.
GitHub Security Advisory: GHSA-9gfh-4fwj-w3rj
Package: com.vaadin:vaadin-server (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 8.0.0, <= 8.28.1
Patched in: 8.28.2

Summary: Vaadin Framework possible file bypass via upload validation on the server-side

Details:
### Description
When the Vaadin Upload's start listener is used to validate metadata about an incoming upload, it is possible to bypass the upload validation. Users of affected versions should apply the upgrade to a more recent Vaadin version.
GitHub Security Advisory: GHSA-9gfh-4fwj-w3rj
Package: com.vaadin:vaadin-server (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 7.0.0, <= 7.7.47
Patched in: 7.7.48

Summary: Vaadin Framework possible file bypass via upload validation on the server-side

Details:
### Description
When the Vaadin Upload's start listener is used to validate metadata about an incoming upload, it is possible to bypass the upload validation. Users of affected versions should apply the upgrade to a more recent Vaadin version.
GitHub Security Advisory: GHSA-f696-867g-2759
Package: io.jenkins.plugins:opentelemetry (MAVEN)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 3.1543.1545.vf5a
Patched in: 3.1543.1545.vf5a

Summary: Jenkins OpenTelemetry Plugin missing permission check allows capturing credentials

Details:
A missing permission check in Jenkins OpenTelemetry Plugin 3.1543.v8446b_92b_cd64 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.
GitHub Security Advisory: GHSA-gm8g-fh49-qq6v
Package: org.jenkins-ci.plugins:global-build-stats (MAVEN)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 347.v32a
Patched in: 347.v32a

Summary: Jenkins global-build-stats Plugin missing permission check can result in graph IDs being enumerated

Details:
Jenkins global-build-stats Plugin 322.v22f4db_18e2dd and earlier does not perform permission checks in its REST API endpoints, allowing attackers with Overall/Read permission to enumerate graph IDs. 

This has been patched in version 347.v32a_eb_0493c4f.
GitHub Security Advisory: GHSA-g2pq-9jr7-w6gv
Package: org.jenkins-ci.plugins:git-client (MAVEN)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-538: Insertion of Sensitive Information into Externally-Accessible File or Directory
Vulnerable versions: < 6.3.3
Patched in: 6.3.3

Summary: Jenkins Git client Plugin file system information disclosure vulnerability

Details:
In Jenkins Git client Plugin 6.3.2 and earlier, Git URL field form validation responses differ based on whether the specified file path exists on the controller when specifying `amazon-s3` protocol for use with JGit, allowing attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system.
GitHub Security Advisory: GHSA-rrpj-r8h7-rm7r
Package: org.apache.dolphinscheduler:dolphinscheduler (MAVEN)
Severity: LOW (CVSS 0.0)
CWE: CWE-276: Incorrect Default Permissions
Vulnerable versions: < 3.3.1
Patched in: 3.3.1

Summary: Apache DolphinScheduler Incorrect Default Permissions Vulnerability

Details:
Incorrect Default Permissions vulnerability in Apache DolphinScheduler.

This issue affects Apache DolphinScheduler: before 3.2.2.

Users are recommended to upgrade to version 3.3.1, which fixes the issue.
GitHub Security Advisory: GHSA-m63c-3rmg-r2cf
Package: org.xwiki.platform:xwiki-platform-skin-skinx (MAVEN)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-23: Relative Path Traversal
Vulnerable versions: >= 4.2-milestone-2, < 16.10.7
Patched in: 16.10.7

Summary: XWiki configuration files can be accessed through jsx and sx endpoints

Details:
### Impact

It's possible to get access and read configuration files by using URLs such as `http://localhost:8080/bin/ssx/Main/WebHome?resource=../../WEB-INF/xwiki.cfg&minify=false`.

This can apparently be reproduced on Tomcat instances.

### Patches

This has been patched in  17.4.0-rc-1, 16.10.7.

### Workarounds

There is no known workaround, other than upgrading XWiki.

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)
* Email us at [Security Mailing List](mailto:security@xwiki.org)

### Attribution

The vulnerability was reported by Gregor Neumann.
GitHub Security Advisory: GHSA-67mf-3cr5-8w23
Package: org.bouncycastle:bc-fips (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 1.0.0, < 1.0.2.6
Patched in: 1.0.2.6

Summary: Bouncy Castle for Java on All (API modules) allows Excessive Allocation

Details:
A resource allocation vulnerability exists in Bouncy Castle for Java (by Legion of the Bouncy Castle Inc.) that affects all API modules. The vulnerability allows attackers to cause excessive memory allocation through unbounded resource consumption, potentially leading to denial of service. The issue is located in the ASN1ObjectIdentifier.java file in the core module.

This issue affects Bouncy Castle for Java: from BC 1.0 through 1.77, from BC-FJA 1.0.0 through 2.0.0.
GitHub Security Advisory: GHSA-67mf-3cr5-8w23
Package: org.bouncycastle:bc-fips (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: = 2.0.0
Patched in: 2.0.1

Summary: Bouncy Castle for Java on All (API modules) allows Excessive Allocation

Details:
A resource allocation vulnerability exists in Bouncy Castle for Java (by Legion of the Bouncy Castle Inc.) that affects all API modules. The vulnerability allows attackers to cause excessive memory allocation through unbounded resource consumption, potentially leading to denial of service. The issue is located in the ASN1ObjectIdentifier.java file in the core module.

This issue affects Bouncy Castle for Java: from BC 1.0 through 1.77, from BC-FJA 1.0.0 through 2.0.0.
GitHub Security Advisory: GHSA-mhpp-875w-9cpv
Package: org.webjars.npm:jquery (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-674: Uncontrolled Recursion
Vulnerable versions: = 3.0.0-rc1
Patched in: 3.0.0

Summary: Denial of Service in jquery

Details:
Affected versions of `jquery` use a lowercasing logic on attribute names. When given a boolean attribute with a name that contains uppercase characters, `jquery` enters into an infinite recursion loop, exceeding the call stack limit, and resulting in a denial of service condition.


## Recommendation

Update to version 3.0.0 or later.
GitHub Security Advisory: GHSA-xjgh-84hx-56c5
Package: org.apache.tomcat.embed:tomcat-embed-core (MAVEN)
Severity: HIGH (CVSS 8.1)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 7.0.0, <= 7.0.81
Patched in: 7.0.82

Summary: Unrestricted Upload of File with Dangerous Type Apache Tomcat

Details:
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
GitHub Security Advisory: GHSA-xjgh-84hx-56c5
Package: org.apache.tomcat.embed:tomcat-embed-core (MAVEN)
Severity: HIGH (CVSS 8.1)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 8.0.0-RC1, <= 8.0.46
Patched in: 8.0.47

Summary: Unrestricted Upload of File with Dangerous Type Apache Tomcat

Details:
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
GitHub Security Advisory: GHSA-xjgh-84hx-56c5
Package: org.apache.tomcat.embed:tomcat-embed-core (MAVEN)
Severity: HIGH (CVSS 8.1)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 8.5.0, <= 8.5.22
Patched in: 8.5.23

Summary: Unrestricted Upload of File with Dangerous Type Apache Tomcat

Details:
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
GitHub Security Advisory: GHSA-xjgh-84hx-56c5
Package: org.apache.tomcat.embed:tomcat-embed-core (MAVEN)
Severity: HIGH (CVSS 8.1)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 9.0.0.M1, <= 9.0.0M27
Patched in: 9.0.1

Summary: Unrestricted Upload of File with Dangerous Type Apache Tomcat

Details:
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
GitHub Security Advisory: GHSA-xjgh-84hx-56c5
Package: org.apache.tomcat:tomcat-catalina (MAVEN)
Severity: HIGH (CVSS 8.1)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 7.0.0, <= 7.0.81
Patched in: 7.0.82

Summary: Unrestricted Upload of File with Dangerous Type Apache Tomcat

Details:
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
GitHub Security Advisory: GHSA-xjgh-84hx-56c5
Package: org.apache.tomcat:tomcat-catalina (MAVEN)
Severity: HIGH (CVSS 8.1)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 8.0.0-RC1, <= 8.0.46
Patched in: 8.0.47

Summary: Unrestricted Upload of File with Dangerous Type Apache Tomcat

Details:
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
GitHub Security Advisory: GHSA-xjgh-84hx-56c5
Package: org.apache.tomcat:tomcat-catalina (MAVEN)
Severity: HIGH (CVSS 8.1)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: >= 8.5.0, <= 8.5.22
Patched in: 8.5.23

Summary: Unrestricted Upload of File with Dangerous Type Apache Tomcat

Details:
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.