#maven

The second wave of the Shai-Hulud supply chain attack has spilled over to the Maven ecosystem after compromising more than 830 packages in the npm registry. The Socket Research Team said it identified a Maven Central package named org.mvnpm:posthog-node:4.18.1 that embeds the same two components associated with Sha1-Hulud: the "setup_bun.js" loader and the main payload "bun_environment.js." "

Apache Druid’s Kerberos authenticator uses a weak fallback secret when the `druid.auth.authenticator.kerberos.cookieSignatureSecret` configuration is not explicitly set. In this case, the secret is generated using `ThreadLocalRandom`, which is not a crypto-graphically secure random number generator. This may allow an attacker to predict or brute force the secret used to sign authentication cookies, potentially enabling token forgery or authentication bypass. Additionally, each process generates its own fallback secret, resulting in inconsistent secrets across nodes. This causes authentication failures in distributed or multi-broker deployments, effectively leading to a incorrectly configured clusters. Users are advised to configure a strong `druid.auth.authenticator.kerberos.cookieSignatureSecret` This issue affects Apache Druid: through 34.0.0. Users are recommended to upgrade to version 35.0.0, which fixes the issue making it mandatory to set `druid.auth.authenticator.kerberos.coo...

### Summary It is observed that OWASP java html sanitizer is vulnerable to XSS if HtmlPolicyBuilder allows `noscript` and `style` tags with `allowTextIn` inside the style tag. This could lead to XSS if the payload is crafted in such a way that it does not sanitise the CSS and allows tags which is not mentioned in HTML policy. ### Details The OWASP java HTML sanitizer is vulnerable to XSS. This only happens when HtmlPolicyBuilder allows `noscript` & `style` tag with `allowTextIn` inside style tags. The following condition is very edge case but if users combine a HtmlPolicyBuilder with any other tags except `noscript` and allow `style` tag with `allowTextIn` inside the style tag then In this case sanitizer would be safe from XSS. This happens because how the browser also perceives `noscript` tags post sanitization. ### PoC 1. Lets create a `HtmlPolicyBuilder` which allows `p, noscript, style` html tags and allows `.allowTextIn("style")`. 2. There are two XSS payloads which very ...

### Summary A reflected cross-site scripting (XSS) vulnerability exists in the WMS GetFeatureInfo HTML output format that enables a remote attacker to execute arbitrary JavaScript code in a victim's browser through specially crafted SLD_BODY parameters. ### Details The WMS service setting that controls HTML auto-escaping is either disabled by default, or completely missing, in the affected versions (see workarounds). ### Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can: 1. Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user. ### Workarounds Changing any of the following WMS service sett...

### Summary A user with no view rights on a page may see the content of an office attachment displayed with the view file macro. ### Details If on a public page is displayed an office attachment from a restricted page, a user with no view rights on the restricted page can view the attachment content, no matter the display type used. ### PoC 1. Install and activate the Pro Macros application 2. Create a page and limit the view rights for a test user 3. Add an attachment to the restricted page 4. Create a new public page 5. Add the view file macro and select the attachment from the restricted page using any display type 6. Login as the test user with restricted view rights 7. The user will see the content despite having no view rights ### Workarounds None ### Impact Private data can be leaked if a user knows the reference to an attachment and has edit rights on a page.

### Impact Users without admin rights have access to `AdminTools.SpammedPages`. ### Details View rights are not restricted only to admin users for `AdminTools.SpammedPages`. While no data is visible to non admin users, the page is still accessible. ### Workarounds Set the view rights for the `AdminTools` space to be only available for the `XWikiAdminGroup`.

### Summary If the "claims_parameter_supported" parameter is activated, it is possible through the "oidc-claims-extension.groovy" script, to inject the value of choice into a claim contained in the id_token or in the user_info. Authorization function requests do not prevent a claims parameter containing a JSON file to be injected. This JSON file allows users to customize claims returned by the "id_token" and "user_info" files. This allows for a very wide range of vulnerabilities depending on how clients use claims. For example, if some clients rely on an email field to identify a user, users can choose to entera any email address, and therefore assume any chosen identity.

### Impact The XML [`Validator`](https://docs.oracle.com/javase/8/docs/api/javax/xml/validation/Validator.html) used by cyclonedx-core-java was not configured securely, making the library vulnerable to XML External Entity (XXE) injection. The fix for GHSA-683x-4444-jxh8 / CVE-2024-38374 has been incomplete in that it only fixed *parsing* of XML BOMs, but not *validation*. ### Patches The vulnerability has been fixed in cyclonedx-core-java version 11.0.1. ### Workarounds If feasible, applications can reject XML documents before handing them to cyclonedx-core-java for validation. This may be an option if incoming CycloneDX BOMs are known to be in JSON format. ### References * The issue was introduced via https://github.com/CycloneDX/cyclonedx-core-java/commit/162aa594f347b3f612fe0a45071693c3cd398ce9 * The issue was fixed via https://github.com/CycloneDX/cyclonedx-core-java/pull/737 * https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#sc...

An XML External Entity (XXE) vulnerability exists in multiple WSO2 products due to improper configuration of the XML parser. The application parses user-supplied XML without applying sufficient restrictions, allowing resolution of external entities. A successful attack could enable a remote, unauthenticated attacker to read sensitive files from the server's filesystem or perform denial-of-service (DoS) attacks that render affected services unavailable.

### Summary The expected `protocDigest` is ignored when protoc is taken from the `PATH`. ### Details The documentation for the `protocDigest` parameter says: > ... Users may wish to specify this if using a `PATH`-based binary ... However, when specifying `<protoc>PATH</protoc>` the `protocDigest` is not actually checked because the code returns here already https://github.com/ascopes/protobuf-maven-plugin/blob/59097aae8062c461129a13dcda2f4116b90a8765/protobuf-maven-plugin/src/main/java/io/github/ascopes/protobufmavenplugin/protoc/ProtocResolver.java#L91-L93 before the digest check: https://github.com/ascopes/protobuf-maven-plugin/blob/59097aae8062c461129a13dcda2f4116b90a8765/protobuf-maven-plugin/src/main/java/io/github/ascopes/protobufmavenplugin/protoc/ProtocResolver.java#L106 ### PoC Specify: ```xml <protoc>PATH</protoc> <protocDigest>sha256:0000000000000000000000000000000000000000000000000000000000000000</protocDigest> ``` And notice how the `protoc` on the `PATH` is not rejec...