#git

### Summary Source code may be stolen during dev when using webpack / rspack builder and you open a malicious web site. ### Details Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject `<script src="http://localhost:3000/_nuxt/app.js">` in their site and run the script. By using `Function::toString` against the values in `window.webpackChunknuxt_app`, the attacker can get the source code. ### PoC 1. Create a nuxt project with webpack / rspack builder. 1. Run `npm run dev` 1. Open `http://localhost:3000` 1. Run the script below in a web site that has a different origin. 1. You can see the source code output in the document and the devtools console. ```js const script = document.createElement('script') script.src = 'http://localhost:3000/_nuxt/app.js' script.addEventListener('load', () => { for (const page in window.webpackChunknuxt_app) { const moduleList = window.webpackChunknuxt_app[page][1] console.log(module...

### Summary Nuxt allows any websites to send any requests to the development server and read the response due to default CORS settings. ### Details While Vite patched the default CORS settings to fix https://github.com/vitejs/vite/security/advisories/GHSA-vg6x-rcgg-rjx6, nuxt uses its own CORS handler by default (https://github.com/nuxt/nuxt/pull/23995). https://github.com/nuxt/nuxt/blob/7d345c71462d90187fd09c96c7692f306c90def5/packages/vite/src/client.ts#L257-L263 That CORS handler sets `Access-Control-Allow-Origin: *`. > [!IMPORTANT] > If on an affected version, it may be possible to opt-out of the default Nuxt CORS handler by configuring `vite.server.cors`. ### PoC 1. Start a dev server in any nuxt project using Vite by `nuxt dev`. 2. Send a fetch request to `http://localhost:3000/_nuxt/app.vue` (`fetch('http://localhost:3000/_nuxt/app.vue')`) from a different origin page. ### Impact Users with the default server.cors option using Vite builder may get the source code stolen ...

Core creation allows users to replace "trusted" configset files with arbitrary configuration Solr instances that (1) use the "FileSystemConfigSetService" component (the default in "standalone" or "user-managed" mode), and (2) are running without authentication and authorization are vulnerable to a sort of privilege escalation wherein individual "trusted" configset files can be ignored in favor of potentially-untrusted replacements available elsewhere on the filesystem.  These replacement config files are treated as "trusted" and can use "<lib>" tags to add to Solr's classpath, which an attacker might use to load malicious code as a searchComponent or other plugin. This issue affects all Apache Solr versions up through Solr 9.7.  Users can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from "FileSystemConfigSetService").  Users are also recommended to upgrade to Solr 9.8.0, which mitigates this ...

Threat hunters have detailed an ongoing campaign that leverages a malware loader called MintsLoader to distribute secondary payloads such as the StealC information stealer and a legitimate open-source network computing platform called BOINC. "MintsLoader is a PowerShell based malware loader that has been seen delivered via spam emails with a link to Kongtuke/ClickFix pages or a JScript file,"

Plus: A hacker finds an issue with Cloudflare’s systems that could reveal app users’ rough locations, and the Trump administration puts a wrench in a key cybersecurity investigation.

The number of CISOs who report directly to the CEO is up sharply in recent years, but many still say it's not enough to secure adequate resources.

### Impact In CI contexts, the IG Publisher CLI uses git commands to determine the URL of the originating repo. If the repo was cloned, or otherwise set to use a repo that uses a username and credential based URL, the entire URL will be included in the built Implementation Guide, exposing username and credential. This does not impact users that clone public repos without credentials, such as those using the auto-ig-build continuous integration infrastructure. ### Patches This problem has been patched in release [1.8.9](https://github.com/HL7/fhir-ig-publisher/releases/tag/1.8.9) ### Workarounds Users should update to 1.8.9 or the latest release OR Users should ensure the IG repo they are publishing does not have username or credentials included in the `origin` URL. Running the command `git remote origin url` should return a URL that contains no username, password, or token. OR Users should run the IG Publisher CLI with the `-repo` parameter and specify a URL that contains no us...

The MITRE framework's applied exercise provides defenders with critical feedback about how to detect and defend against common, but sophisticated, attacks.

### Summary If an attacker can control the input to the `asteval` library, they can bypass asteval's restrictions and execute arbitrary Python code in the context of the application using the library. ### Details The vulnerability is rooted in how `asteval` performs handling of `FormattedValue` AST nodes. In particular, the [`on_formattedvalue`](https://github.com/lmfit/asteval/blob/cfb57f0beebe0dc0520a1fbabc35e66060c7ea71/asteval/asteval.py#L507) value uses the [dangerous format method of the str class](https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/), as shown in the vulnerable code snippet below: ```py def on_formattedvalue(self, node): # ('value', 'conversion', 'format_spec') "formatting used in f-strings" val = self.run(node.value) fstring_converters = {115: str, 114: repr, 97: ascii} if node.conversion in fstring_converters: val = fstring_converters[node.conversion](val) fmt = '{__fstring__}' if node.f...

### Impact summary In some circumstances, debug artifacts uploaded by the CodeQL Action after a failed code scanning workflow run may contain the environment variables from the workflow run, including any secrets that were exposed as environment variables to the workflow. Users with read access to the repository would be able to access this artifact, containing any secrets from the environment. For some affected workflow runs, the exposed environment variables in the debug artifacts included a valid `GITHUB_TOKEN` for the workflow run, which has access to the repository in which the workflow ran, and all the permissions specified in the workflow or job. The `GITHUB_TOKEN` is valid until the job completes or 24 hours has elapsed, whichever comes first. Environment variables are exposed only from workflow runs that satisfy all of the following conditions: - Code scanning workflow configured to scan the Java/Kotlin languages. - Running in a repository containing Kotlin source code. - R...