The npm package @ikyyjee/ikyysinggle version 1.7.7 is part of a large family of malicious forks of the Baileys WhatsApp Web library. These forks inject code that silently subscribes the victim's authenticated WhatsApp account to attacker-controlled channels without user consent. The target channels are obfuscated or dynamically fetched to evade detection. This malicious behavior abuses the installer's WhatsApp session to increase subscribers for attacker channels but does not steal credentials or execute arbitrary code.
The npm package @ikyyjee/ikyysingle version 1.7.8 is part of a large family of malicious forks of the Baileys WhatsApp Web library. These forks inject code that silently subscribes the victim's authenticated WhatsApp account to attacker-controlled channels without user consent. The target channels are obfuscated or dynamically fetched, and the malicious code uses the victim's own WhatsApp session to issue subscription requests. This behavior does not involve credential theft, persistence, or arbitrary code execution.
The npm package 'waie-crash-baileys' contains malicious code or depends on a malicious package. Installing or running this package can lead to full compromise of the affected computer, potentially exposing all stored secrets and keys. Immediate removal of the package and rotation of all secrets from a different machine is strongly advised.
Handlebars provides the power necessary to let users build semantic templates. From 4.0.0 until 4.7.10, Handlebars.precompile() uses quotedString() in lib/handlebars/compiler/code-gen.js to emit static template text into generated JavaScript without escaping sequences that terminate an enclosing HTML script element. When an application precompiles attacker-controlled template text and embeds the generated source directly in an inline script element, a closing script delimiter can end the element and cause following attacker-controlled markup to be parsed and executed. Ordinary server-side rendering and precompiled templates served as external JavaScript files are not affected. This issue is fixed in version 4.7.10.
The npm package css-jptvix-polyfill version 1.0.0 contains malicious code that mimics internal Wix thunderbolt modules to trigger its payload when imported. Upon loading, it executes system commands to gather environment details and sends this sensitive information to a hardcoded external server. It also downloads and executes attacker-controlled JavaScript, potentially establishing a reverse shell on the victim's machine. This behavior indicates a dependency confusion attack targeting Wix thunderbolt builds.
CVE-2026-106446 is a critical code injection vulnerability in handlebars.js versions 4.0.0 up to but not including 4.7.10. The vulnerability arises because Handlebars.compile() and Handlebars.precompile() accept pre-parsed AST objects without fully validating all node values, allowing untrusted input objects to inject arbitrary JavaScript code. This can lead to remote code execution on the server or malicious code execution in client environments where precompiled templates are used. Applications passing untrusted objects instead of strings to these functions are affected. The vulnerability has a CVSS score of 9.8, indicating critical severity.
Handlebars provides the power necessary to let users build semantic templates. From 3.0.0 until 4.7.10, Handlebars lookupProperty returns Function.prototype.constructor before applying the prototype-access deny list because constructor is an own property of Function.prototype. When an attacker can render a controlled template with allowProtoMethodsByDefault enabled and an accessible function in the template context, the template can traverse from that function through its prototype to Function.prototype and then obtain the Function constructor through the own-property bypass. This permits attacker-controlled JavaScript to execute with the server application's privileges. This issue is fixed in version 4.7.10.
CVE-2026-106119 is a vulnerability in langchainjs's MongoDBChatMessageHistory component where session identifiers are not properly validated at runtime. This allows specially crafted session identifiers to be interpreted as MongoDB query conditions instead of literal strings. An attacker able to invoke chat-history operations could potentially read, modify, or delete other users' conversation histories if multiple users' data share the same collection. The issue is fixed in @langchain/mongodb version 1.3.1 and later.
### Summary
A DOM Clobbering vulnerability exists in Quasar's `openURL()` utility when handling the iOS `SafariViewController` bridge.
The vulnerable implementation only checks whether `window.SafariViewController` exists before invoking it as a native bridge object. An attacker who can inject HTML content containing a named element such as `<a id="SafariViewController">` can cause the browser to expose that element as `window.SafariViewController`.
When `openURL()` is later called in an iOS environment, Quasar incorrectly treats the DOM element as the native bridge object and attempts to invoke bridge methods that do not exist, resulting in:
```
TypeError: window.SafariViewController.isAvailable is not a function
```
This can cause client-side denial of service and break navigation-related workflows in Quasar applications.
### Details
Quasar provides the `openURL()` utility to open external URLs. On iOS platforms, this utility supports integration with the native `SafariViewController` bridge.
The vulnerable code is located in:
```
ui/src/utils/open-url/open-url.js
````
The affected logic is:
```javascript
if (Platform.is.ios && window.SafariViewController !== void 0) {
window.SafariViewController.isAvailable(available => {
if (available) {
window.SafariViewController.show({ url }, noop, reject)
}
})
}
````
The issue is that Quasar only verifies that `window.SafariViewController` is not `undefined`. It does not verify whether the value is the expected native bridge object or whether required methods such as `isAvailable()` and `show()` are valid functions.
Modern browsers expose elements with specific `id` or `name` attributes as properties of the global `window` object. Therefore, attacker-controlled HTML such as:
```html
<a id="SafariViewController"></a>
```
can cause:
```javascript
window.SafariViewController
```
to resolve to an `HTMLAnchorElement` instead of the expected native bridge object.
When Quasar later executes:
```javascript
window.SafariViewController.isAvailable(...)
```
the DOM element is incorrectly treated as the bridge object, causing:
```
TypeError: window.SafariViewController.isAvailable is not a function
```
The root cause is insufficient validation of browser-controlled global properties before using them as trusted native bridge objects.
The vulnerability was verified through the Quasar `QEditor` rendering path. When attacker-controlled HTML content is rendered into the DOM and creates the `SafariViewController` named element, subsequent calls to `openURL()` fail.
Additional component-level affected paths were identified in `QSelect` and `QChatMessage` when applications enable HTML rendering features and provide attacker-controlled content. These paths require specific application configurations and were not used as the primary end-to-end reproduction.
### PoC
#### Steps to reproduce
1. Render attacker-controlled HTML content through a Quasar HTML rendering component such as `QEditor`.
2. Insert the following payload:
```html
<a id="SafariViewController" href="#bridge">
SafariViewController
</a>
````
3. Verify that the browser exposes the element as a global property:
```javascript
window.SafariViewController
```
The value resolves to the injected DOM element instead of the expected native bridge object.
4. Trigger a normal workflow that invokes:
```javascript
openURL('https://example.com')
```
5. Observe the browser console output:
```
TypeError: window.SafariViewController.isAvailable is not a function
```
The URL opening workflow fails because Quasar attempts to invoke native bridge methods on the DOM element.
The same underlying issue can also affect other HTML rendering paths such as `QSelect` and `QChatMessage` when attacker-controlled HTML is rendered and the application later calls `openURL()`.
### Impact
This vulnerability is a client-side DOM Clobbering and type confusion issue affecting Quasar applications that use the iOS `SafariViewController` integration. An attacker who can control HTML content rendered into the application DOM may cause Quasar's `openURL()` functionality to fail by replacing the expected native bridge object with a DOM element through browser named property resolution.
Potentially affected workflows include external URL navigation, OAuth/login redirects, help or documentation links, payment flows, third-party service redirects, and other application actions that rely on URL opening functionality.
The confirmed impact is client-side denial of service and navigation or workflow disruption. When the vulnerable condition is triggered, Quasar throws an exception while attempting to invoke methods on the clobbered `SafariViewController` object, preventing the expected URL opening behavior.
Payload CMS versions before 3.90.0 and canary versions before 4.0.0-canary.34 have a vulnerability allowing local upload configurations that accept XML files to store XML files and stylesheets that execute JavaScript in the Payload origin when opened by a logged-in user. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
### Impact
An authenticated user could overwrite an existing S3 object belonging to another upload collection, bypassing that collection’s access controls and prior file validation.
You are affected if ALL of these are true:
- Client uploads are enabled for multiple collections that share an S3 bucket.
- useCompositePrefixes is not configured or is set to `false`.
### Patches
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
### Workarounds
Disable client uploads until you can upgrade.
### **Impact**
An unauthenticated attacker who knows an account’s email address or username could trigger Payload’s account lockout mechanism and prevent that user from signing in.
You are affected if:
* Using an affected Payload version with an auth-enabled collection that uses local authentication and account lockout.
Applications that do not use Payload local authentication are not affected.
### **Patches**
Successful password resets now clear the account’s lockout state. The forgot-password flow also enforces a configurable minimum interval between reset emails, which defaults to 15 seconds.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## Impact
Under certain conditions, an authenticated user with permission to modify uploads could cause unintended files to be removed during file cleanup. This may result in data loss or service disruption.
You are affected if:
- You use Payload upload collections with local file storage.
- Untrusted authenticated users can update or delete uploads.
Deployments that restrict upload management to trusted users are less exposed.
## Patches
Payload now validates uploaded filenames and ensures file cleanup remains within the configured upload directory.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## Workarounds
Restrict upload update and deletion operations to trusted users and validate submitted filenames. These measures are temporary mitigations. Upgrading to a patched version is recommended.
### Impact
An authenticated user limited to one tenant could create a record in another tenant. This requires the multi-tenant plugin with at least one tenant-enabled collection.
Reads and direct edits to an existing target-tenant document were not bypassed.
You are affected if:
- You are using @payloadcms/plugin-multi-tenant
### Patches
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
### Workarounds
You can add access control with `accessResultOverride` on the multi-tenant collection config to ensure a user has access to the tenant before creating.
PayloadCMS versions from 3.0.0 up to but not including 3.90.0, and certain 4.0.0-canary versions, contain an authentication bypass vulnerability. This occurs when a custom field is mapped to a reserved authentication claim name, allowing unintended values to be placed in authentication tokens at login. The issue is fixed in version 3.90.0.
## Impact
A malicious SVG file upload could bypass sanitization, be stored, and execute attacker-controlled JavaScript (XSS) after a user downloads it and opens it.
**You are affected if:**
- You have a collection configured to upload and allow SVG files which can then be downloaded by users.
## Patches
The fix validates SVG content on every upload path and hardens SVG/XML delivery so stored SVGs cannot frame attacker content.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## Workarounds
Disallow SVG uploads, or serve uploaded SVGs as downloads with Content-Disposition: attachment and a strict CSP. These mitigations reduce exposure but do not replace upgrading when the patched release is available.
## Impact
Under certain external upload configurations, Payload could send authentication data to a destination that was not verified as trusted. If the affected request contained a valid session, this could expose that session to an unintended recipient.
**You are affected if:**
- You have enabled external URL-based upload retrieval, where authenticated requests can trigger it.
## Patches
Payload now validates the destination before forwarding authentication data and reapplies that validation when a request changes destination.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## Workarounds
It is recommended to update all Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
If you cannot, a valid workaround exists:
- Disable external URL-based upload retrieval where practical.
- If you cannot disable it, configure the upload header filter to remove authentication data from outbound file requests.
- Restrict access to the affected upload functionality.
## Impact
When using the default tenant array field access, an authenticated user could assign themselves to other tenants.
**You are affected if:**
- You are using `@payloadcms/plugin-multi-tenant`
If you configure the tenants arrayFieldAccess.create/update functions, a secured replacement membership field, you are not affected by this specific default behavior.
## Patches
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## Workarounds
Configure tenants arrayFieldAccess.create and tenants arrayFieldAccess.update so only trusted users authorized for all tenants can modify memberships.
## Impact
An attacker can submit a request to a specific endpoint that permits collection documents to be updated regardless of access control and field level access control.
**You are affected if:**
- You are configuring `orderable: true` with any collection or join field.
## Patches
In the patched version access control is properly enforced.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
PayloadCMS versions prior to 3.90.0 and canary versions before 4.0.0-canary.34 contain a code injection vulnerability in the public first-register operation. This flaw allows remote code execution when local authentication is enabled and no initial user has been created. The vulnerability is addressed in versions 3.90.0 and 4.0.0-canary.34.