Security
Headlines
HeadlinesLatestCVEs

Latest News

GHSA-j2xj-h7w5-r7vp: Mailgen: HTML injection vulnerability in plaintext e-mails

### Impact An HTML injection vulnerability in plaintext e-mails generated by Mailgen has been discovered. Your project is affected if you make use of the `Mailgen.generatePlaintext(email);` method and pass in user-generated content. The issue has been discovered and reported by Edoardo Ottavianelli (@edoardottt). ### Patches The vulnerability has been patched in commit https://github.com/eladnava/mailgen/commit/741a0190ddae0f408b22ae3b5f0f4c3f5cf4f11d and released to `npm` in version `2.0.30`. ### Workarounds Strip all HTML tags yourself before passing any content into `Mailgen.generatePlaintext(email);`. Thanks to Edoardo Ottavianelli (@edoardottt) for discovering and reporting this vulnerability.

ghsa
#vulnerability#web#nodejs#git#auth
GHSA-g38c-wxjf-xrh6: `git-comiters` Command Injection vulnerability

## Background on the vulnerability This vulnerability manifests with the library's primary exported API: `gitCommiters(options, callback)` which allows specifying options such as `cwd` for current working directory and `revisionRange` as a revision pointer, such as `HEAD`. However, the library does not sanitize for user input or practice secure process execution API to separate commands from their arguments and as such, uncontrolled user input is concatenated into command execution. ## Exploit 1. Install `git-commiters@0.1.1` or earlier 2. Initiaizlie a new Git directory with commits in it 3. Create the following script in that directory: ```js var gitCommiters = require("git-commiters"); var options = { cwd: "./", revisionRange: "HEAD; touch /tmp/pwn; #", }; gitCommiters(options, function (err, result) { if (err) console.log(err); else console.log(result); }); ``` 3. Observe new file created on disk at `/tmp/pwn` The git commiters functionality works as expected, too, ...

GHSA-vh25-5764-9wcr: @conventional-changelog/git-client has Argument Injection vulnerability

## Background on exploitation This vulnerability manifests with the library's `getTags()` API, which allows specifying extra parameters passed to the `git log` command. In another API by this library - `getRawCommits()` there are secure practices taken to ensure that the extra parameter `path` is unable to inject an argument by ending the `git log` command with the special shell syntax `--`. However, the library does not follow the same practice for `getTags()` not attempts to sanitize for user input, validate the given params, or restrcit them to an allow list. Nor does it properly pass command-line flags to the `git` binary using the double-dash POSIX characters (`--`) to communicate the end of options. Thus, allowing users to exploit an argument injection vulnerability in Git due to the `--output=` command-line option that results with overwriting arbitrary files. ## Exploit 1. Install `@conventional-changelog/git-client@1.0.1` or earlier 2. Prepare a Git directory to be used as...

Bitcoin continues to increase its institutional popularity 

Not long ago, the mere idea that cryptocurrencies could ever be integrated into mainstream finance would have seemed…

GHSA-mm7x-qfjj-5g2c: Ammonia incorrectly handles embedded SVG and MathML leading to mutation XSS after removal

Affected versions of this crate did not correctly strip namespace-incompatible tags in certain situations, causing it to incorrectly account for differences between HTML, SVG, and MathML. This vulnerability only has an effect when the `svg` or `math` tag is allowed, because it relies on a tag being parsed as html during the cleaning process, but serialized in a way that causes in to be parsed as xml by the browser. Additionally, the application using this library must allow a tag that is parsed as raw text in HTML. These [elements] are: * title * textarea * xmp * iframe * noembed * noframes * plaintext * noscript * style * script Applications that do not explicitly allow any of these tags should not be affected, since none are allowed by default. [elements]: https://github.com/servo/html5ever/blob/57eb334c0ffccc6f88d563419f0fbeef6ff5741c/html5ever/src/tree_builder/rules.rs

ComicForm and SectorJ149 Hackers Deploy Formbook Malware in Eurasian Cyberattacks

Organizations in Belarus, Kazakhstan, and Russia have emerged as the target of a phishing campaign undertaken by a previously undocumented hacking group called ComicForm since at least April 2025. The activity primarily targeted industrial, financial, tourism, biotechnology, research, and trade sectors, cybersecurity company F6 said in an analysis published last week. The attack chain involves

Fake Ukrainian Police Emails Spread New CountLoader Malware Loader

A new malware loader, CountLoader, has been discovered by cybersecurity firm Silent Push. This threat is linked to prominent Russian ransomware gangs, including LockBit, BlackBasta, and Qilin, and is being used as an initial access broker.

Beware of Zelle transfer scams

Zelle scams are back, or perhaps they never went away. Here's what to look out for.

Airport Chaos Shows Human Impact of 3rd-Party Attacks

Major EU airports such as Heathrow were disrupted over the weekend after a cyberattack hit the provider of check-in kiosk software, which caused delays and flight cancellations.

GHSA-9ggr-2464-2j32: Authlib: JWS/JWT accepts unknown crit headers (RFC violation → possible authz bypass)

## Summary Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (`crit`), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, `bork` or `cnf`) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation. ## Affected Component and Versions - Library: Authlib (JWS verification) - API: `authlib.jose.JsonWebSignature.deserialize_compact(...)` - Version tested: 1.6.3 - Configuration: Default; no allowlist or special handling for `crit` ## Details RFC 7515 (JWS) §4.1.11 defines `crit` as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in `crit`, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., `cnf` from RFC 7800) are often conveyed via `crit`. Observed behavior with Authlib 1...