ghsa

### Overview An attacker with access to the SQL Lab and the ab_user and ab_user_role tables can elevate his privileges to become administrator. ### Details On a more general level, diverse tables who are supposed to be only readable can be modified using the WITH … AS and RETURNING keywords. Modification of the table key_value can also be done, which could lead to a Remote Code Execution (cf. "V7 - Insecure deserialization leading to remote code execution" report vulnerability). ### Proof of Concept Some tables are supposed to accept only SELECT requests from the SQL tab. - Attempt to create a new user injected_admin into the ab_user table: [PoC_1](https://github.com/orangecertcc/security-research/blob/main/CVE-2023-40610/PoC_1.png) But this protection can be bypassed by using the WITH … AS () syntax with RETURNING value after the INSERT / UPDATE / DELETE query. INSERT query accepted by the database due to the use of WITH … AS ( … RETURNING ) syntax: WITH a AS ( INSERT INTO ab_use...

Validation of an XML Signature requires verification that the hash value of the related XML-document (after any optional transformations and/or normalizations) matches a specific DigestValue-value, but also that the cryptografic signature on the SignedInfo-tree (the one that contains the DigestValue) verifies and matches a trusted public key. Within the simpleSAMLphp/xml-security library (https://github.com/simplesamlphp/xml-security), the hash is being validated using SignedElementTrait::validateReference, and the signature is being verified in SignedElementTrait::verifyInternal https://github.com/simplesamlphp/xml-security/blob/master/src/XML/SignedElementTrait.php:  What stands out is that the signature is being calculated over the canonical version of the SignedInfo-tree. The validateReference method, however, uses the original non-canonicalized version of SignedInf...

Improper Input Validation vulnerability in Apache Tomcat. Tomcat from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.1.15, from 9.0.0-M1 through 9.0.82, and from 8.5.0 through 8.5.95 did not correctly parse HTTP trailer headers. A trailer header that exceeded the header size limit could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy. Users are recommended to upgrade to version 11.0.0-M11 onwards, 10.1.16 onwards, 9.0.83 onwards or 8.5.96 onwards, which fix the issue.

Once an user is authenticated on Jolokia, he can potentially trigger arbitrary code execution.  In details, in ActiveMQ configurations, jetty allows org.jolokia.http.AgentServlet to handler request to /api/jolokia org.jolokia.http.HttpRequestHandler#handlePostRequest is able to create JmxRequest through JSONObject. And calls to org.jolokia.http.HttpRequestHandler#executeRequest. Into deeper calling stacks, org.jolokia.handler.ExecHandler#doHandleRequest is able to invoke through refection. And then, RCE is able to be achieved via jdk.management.jfr.FlightRecorderMXBeanImpl which exists on Java version above 11. 1 Call newRecording. 2 Call setConfiguration. And a webshell data hides in it. 3 Call startRecording. 4 Call copyTo method. The webshell will be written to a .jsp file. The mitigation is to restrict (by default) the actions authorized on Jolokia, or disable Jolokia. A more restrictive Jolokia configuration has been defined in default ActiveMQ distribution. We encourage ...

An arbitrary file read vulnerability in ureport v2.2.9 allows a remote attacker to arbitrarily read files on the server by inserting a crafted path.

An authenticated attacker with update datasets permission could change a dataset link to an untrusted site by spoofing the HTTP Host header, users could be redirected to this site when clicking on that specific dataset. This issue affects Apache Superset versions before 3.0.0.

An authenticated malicious user could initiate multiple concurrent requests, each requesting multiple dashboard exports, leading to a possible denial of service. This issue affects Apache Superset: before 3.0.0

An authenticated user with read permissions on database connections metadata could potentially access sensitive information such as the connection's username. This issue affects Apache Superset before 3.0.0.

A race condition in go-resty can result in HTTP request body disclosure across requests. This condition can be triggered by calling sync.Pool.Put with the same *bytes.Buffer more than once, when request retries are enabled and a retry occurs. The call to sync.Pool.Get will then return a bytes.Buffer that hasn't had bytes.Buffer.Reset called on it. This dirty buffer will contain the HTTP request body from an unrelated request, and go-resty will append the current HTTP request body to it, sending two bodies in one request. The sync.Pool in question is defined at package level scope, so a completely unrelated server could receive the request body.

In Spring Boot versions 2.7.0 - 2.7.17, 3.0.0-3.0.12 and 3.1.0-3.1.5, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition. Specifically, an application is vulnerable when all of the following are true: * the application uses Spring MVC or Spring WebFlux * org.springframework.boot:spring-boot-actuator is on the classpath