#java

# 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...

Avery has confirmed its website was compromised by a credit card skimmer that potentially affected over 60,000 customers.

Cybersecurity researchers have detailed an attack that involved a threat actor utilizing a Python-based backdoor to maintain persistent access to compromised endpoints and then leveraged this access to deploy the RansomHub ransomware throughout the target network. According to GuidePoint Security, initial access is said to have been facilitated by means of a JavaScript malware downloaded named

### Impact In RESTEasy the insecure `File.createTempFile()` is used in the `DataSourceProvider`, `FileProvider` and `Mime4JWorkaround` classes which creates temp files with insecure permissions that could be read by a local user. ### Patches Fixed in the following pull requests: * https://github.com/resteasy/resteasy/pull/3409 (7.0.0.Alpha1) * https://github.com/resteasy/resteasy/pull/3423 (6.2.3.Final) * https://github.com/resteasy/resteasy/pull/3412 (5.0.6.Final) * https://github.com/resteasy/resteasy/pull/3413 (4.7.8.Final) * https://github.com/resteasy/resteasy/pull/3410 (3.15.5.Final) ### Workarounds There is no workaround for this issue. ### References * https://nvd.nist.gov/vuln/detail/CVE-2023-0482 * https://bugzilla.redhat.com/show_bug.cgi?id=2166004 * https://github.com/advisories/GHSA-jrmh-v64j-mjm9

Evidence suggests that some of the payloads and extensions may date as far back as April 2023.