#java

An extension point in Jenkins allows selectively disabling cross-site request forgery (CSRF) protection for specific URLs. Bitbucket Server Integration Plugin implements this extension point to support OAuth 1.0 authentication. In Bitbucket Server Integration Plugin 2.1.0 through 4.1.3 (both inclusive) this implementation is too permissive, allowing attackers to craft URLs that would bypass the CSRF protection of any target URL. Bitbucket Server Integration Plugin 4.1.4 restricts which URLs it disables cross-site request forgery (CSRF) protection for to the URLs that needs it.

### Summary Despite normal text rendering as LaTeX expressions, preventing XSS, the library also provides users with commands which may modify HTML, such as the `\htmlData` command, and the lack of escaping leads to XSS. ### Details Overall in the code, other than in the `test` folder, no functions escaping HTML can be seen. ### PoC 1. Go to https://cortexjs.io/mathlive/demo/ 2. Paste either `\htmlData{><img/onerror=alert(1)"src=}{}` or `\htmlData{x=" ><img/onerror=alert(1) src>}{}` in the LaTeX textarea. ### Impact MathLive users who render untrusted mathematical expressions could encounter malicious input using \htmlData that runs arbitrary JavaScript, or generate invalid HTML.

### Impact [Undici `fetch()` uses Math.random()](https://github.com/nodejs/undici/blob/8b06b8250907d92fead664b3368f1d2aa27c1f35/lib/web/fetch/body.js#L113) to choose the boundary for a multipart/form-data request. It is known that the output of Math.random() can be predicted if several of its generated values are known. If there is a mechanism in an app that sends multipart requests to an attacker-controlled website, they can use this to leak the necessary values. Therefore, An attacker can tamper with the requests going to the backend APIs if certain conditions are met. ### Patches This is fixed in 5.28.5; 6.21.1; 7.2.3. ### Workarounds Do not issue multipart requests to attacker controlled servers. ### References * https://hackerone.com/reports/2913312 * https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f

### Summary The researcher discovered zero-day vulnerability Cross-Site Scripting (XSS) vulnerability in the code which translates the XLSX file into a HTML representation and displays it in the response. ### Details When generating the HTML from an xlsx file containing multiple sheets, a navigation menu is created. This menu includes the sheet names, which are not sanitized. As a result, an attacker can exploit this vulnerability to execute JavaScript code. ```php // Construct HTML $html = ''; // Only if there are more than 1 sheets if (count($sheets) > 1) { // Loop all sheets $sheetId = 0; $html .= '<ul class="navigation">' . PHP_EOL; foreach ($sheets as $sheet) { $html .= ' <li class="sheet' . $sheetId . '"><a href="#sheet' . $sheetId . '">' . $sheet->getTitle() . '</a></li>' . PHP_EOL; ++$sheetId; } $html .= '</ul>' . PHP_EOL; } ``` ...

# Authenticated Stored XSS in YesWiki <= 4.4.5 ### Summary It is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded. This Proof of Concept has been performed using the followings: - YesWiki v4.4.5 (`doryphore-dev` branch, latest) - Docker environnment (`docker/docker-compose.yml`) - Docker v27.5.0 - Default installation ### Details The vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. This part of the code is managed in `tools/attach/libs/attach.lib.php` and the faulty function is **[showFileNotExits()](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/att...

# Unauthenticated DOM Based XSS in YesWiki <= 4.4.5 ### Summary It is possible for any end-user to craft a DOM based XSS on all of YesWiki's pages which will be triggered when a user clicks on a malicious link. This Proof of Concept has been performed using the followings: - YesWiki v4.4.5 (`doryphore-dev` branch, latest) - Docker environnment (`docker/docker-compose.yml`) - Docker v27.5.0 - Default installation ### Details The vulnerability makes use of the search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked. This part of the code is managed by `tools/tags/handlers/page/listpages.php`, and **[this piece of code](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/tags/handlers/page/listpages.php#L84)** is responsible for the vulnerability: ```php $output .= '<div class="alert alert-info">...

### Summary This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service. Moreover, this issue can also be maneuvered into performing a Blind SSRF attack. ### Details The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production. The **lookupWebFinger** function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor’s object. On Fedify, two client-facing functions implement the *...

Sneaky 2FA: New Phishing-as-a-Service targets Microsoft 365, leveraging sophisticated evasion techniques and a Telegram-based platform to steal credentials.…

### Impact KaTeX users who render untrusted mathematical expressions with `renderToString` could encounter malicious input using `\htmlData` that runs arbitrary JavaScript, or generate invalid HTML. ### Patches Upgrade to KaTeX v0.16.21 to remove this vulnerability. ### Workarounds - Avoid use of or turn off the `trust` option, or set it to forbid `\htmlData` commands. - Forbid inputs containing the substring `"\\htmlData"`. - Sanitize HTML output from KaTeX. ### Details `\htmlData` did not validate its attribute name argument, allowing it to generate invalid or malicious HTML that runs scripts. ### For more information If you have any questions or comments about this advisory: - Open an issue or security advisory in the [KaTeX repository](https://github.com/KaTeX/KaTeX/) - Email us at [[email protected]](mailto:[email protected])

### Impact Enabling frame-ancestors: 'self' grants any JupyterHub user the ability to extract formgrader content by sending malicious links to users with access to formgrader, at least when using the default JupyterHub configuration of `enable_subdomains = False`. #1915 disables a protection which would allow user Alice to craft a page embedding formgrader in an IFrame. If Bob visits that page, his credentials will be sent and the formgrader page loaded. Because Alice's page is on the same Origin as the formgrader iframe, Javasript on Alice's page has _full access_ to the contents of the page served by formgrader using Bob's credentials. ### Workarounds - Disable `frame-ancestors: self`, or - enable per-user and per-service subdomains with `JupyterHub.enable_subdomains = True` (then even if embedding in an IFrame is allowed, the host page does not have access to the contents of the frame). ### References JupyterHub documentation on why and when `frame-ancestors: self` is insecure...