An arbitrary file leak (restricted read) in Jenkins that can be used to leak sensitive information in some scenarios. Ultimately the vulnerability comes from Jenkins’ use of args4j, a small but well known Java library for parsing command line arguments. One of the features of args4j is abusable, as it can take any arguments that are prefixed with @ and treat the argument as a path, and resolve the file contents in that path as the argument. By invoking the Jenkins CLI tool and getting file contents echoed in arguments for enable-job, connect-node, or help, an error message complaining about too many arguments can echo out some of the file contents.

This can be reached via jenkins-cli directly or by sending a POST request to the /cli endpoint. Exploiting these vulns though would require an attacker to have access to the Jenkins CLI. They call out configurations that allow anonymous registration and anonymous read permission as particularly susceptible to this bug.

Two cross-site scripting vulnerabilities stemming from the handling of clipboard data in Excalidraw and Microsoft Whiteboard. One allows straight forward exploitation, where as the other has a bit of an iframe trick to it.

The first issue revolves around a Cross-Site Scripting (XSS) vulnerability arising from the mishandling of clipboard data within Excalidraw. Specifically, HTML elements in clipboard data will make their way into a, renderElementToSvg For links the link will be directly used in an anchor tag’s href property. ALlowing it to point to javascript: URLs that will result in cross-site scripting.

The second vulnerability began with the discovery of support for an undocumented tag (again coming through the clipboard data), the iframe tag. While the code would properly sanitize the frame’s src value to prevent JavaScript URLs, it supported one other property: sandbox. The sandbox property is generally used to describe behavior restrictions/allowances on the framed content. The author was able to use the allow-top-navigation value in order to allow his iframe to redirect the frame to a JavaScript URL.

In addition to the vulnerabilities the post dives a bit more into the hunting process, some discussion about how to make exploitation more practical that may also be of interest.

We have an unnamed dashboard application here that allows users to specify objects that will be rendered into the dashboard through JSON blobs. Users can provide dashboard templates in the form of a JSON blob, including an item array of which items to render. There is also a feature to export the dashboard as a PDF document which it handled by a headless browser.

The problem stems from the supported iframeobject type which produces an iframe. While these frames could not be pointed at internal URLs due to the requirement that the URLs be https. Frames within the framed page did not have this restriction. An attacker could render a remote https URL, and on that page include an iframe to an internal address, when rendered as a PDF they would visually see the response page.

This was used to access an internal application running on localhost which would print among other things session tokens of active users.

This one comes down to a normalization difference between Cloudflare’s CDN and the ChatGPT backend server. The Cloudflare CDN was setup to cache all requests under the /share/ endpoint, and the determination of whether a path matches would happen before any percent-encoded characters were decoded. On the backend however the path would be routed based on the decoded version of the URL. So a request to an endpoint like /share/%2F..%2F/api/auth/session would get cached by Cloudflare because it was under the /share/ endpoint, but the content served by ChatGPT would be from /api/auth/session which included the user’s access_token.