A vulnerability in Fiber v2.52.1 and v2.52.2 CORS middleware allowed wildcard origins to be matched incorrectly without enforcing a dot boundary or scheme check. This caused origins with hosts ending in the base domain, but not actual subdomains (e.g., https://evil-example.com for https://*.example.com), to be reflected in Access-Control-Allow-Origin with credentials allowed. The issue was fixed in v2.52.3 by improving the origin matching logic.
The NationalSecurityAgency/emissary package contains a vulnerability in its URL validation logic within NavAction.java. The regex intended to restrict URLs allows protocol-relative URLs (e.g., //evil.com) and single-slash scheme variants (e.g., http:/evil.com) to bypass validation. This flaw enables server-side request forgery (SSRF) and open redirect attacks. The vulnerability affects versions prior to 8.51.0, which includes the commit e2078417464b that introduced the flawed regex. The issue is rated medium severity with a CVSS score of 4.8.
The tefeest-npm-com-test package contains malicious code that can fully compromise any computer on which it is installed or running. It is advised to immediately rotate all secrets and keys from a different, uncompromised machine. Removing the package alone may not eliminate all malicious software introduced by it.
changelog.com before commit 7b35e829 contains a missing authorization vulnerability that allows unauthenticated attackers to read unpublished content via preview routes in PostController, NewsIssueController and NewsItemController. Attackers can enumerate hashid post IDs, sequential newsletter slugs and integer news IDs against preview endpoints to read draft posts, unsent newsletters and declined news items.
Brotli2Bitcoin is a purposely vulnerable web application exposed to the internet as a live hacking challenge with a $1,000 bitcoin bounty for achieving remote code execution (RCE). The challenge is streamed live, showing all attack attempts in real time. The scope is limited strictly to brotli2bitcoin.com, with authorized testing and rules to prevent denial of service or attacks outside the target. The first verified RCE that runs a specific command and reports the flag wins the bitcoin prize. This is a controlled security research exercise rather than an active threat or vulnerability disclosure.
Lightdash is an open source business intelligence platform. In affected versions through 0.3213.0, the dbt Cloud webhook `POST /api/v1/projects/{projectUuid}/dbt-cloud/webhook` has no authentication middleware or signature validation. In `packages/backend/src/controllers/projectController.ts`, `testWebhook()` accepts `accountId` and `runId` from a `job.run.completed` request and passes them to `createPreviewWithExplores()` in `packages/backend/src/services/ProjectService/ProjectService.ts`. These unsanitized values are interpolated into the server-side dbt Cloud API URL, which is requested with the victim project's API key in the `Authorization` header. Path traversal through `accountId` changes the requested path on `cloud.getdbt.com` without changing its host, so the credential-bearing request reaches an attacker-influenced path on that fixed host. The advisory claims API-key theft, but the supplied evidence does not establish that the attacker can observe the `Authorization` header. The unauthenticated webhook also allows preview creation. The target must be a `dbt Cloud IDE` project and the attacker must know its `projectUuid`; the UUID is not enumerable but can be discovered in shared or multi-tenant contexts. Version 0.3214.0 fixes identifier path traversal and verifies webhook HMAC signatures only when a secret is configured; without a secret, unsigned webhooks continue to be processed.
Missing Authorization vulnerability in VideoWhisper.com Broadcast Live Video videowhisper-live-streaming-integration allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Broadcast Live Video: from n/a through 7.3.9.
Server-Side Request Forgery (SSRF) vulnerability in Apache Camel A2A component.
This issue affects Apache Camel: from 4.21.0 before 4.22.2.
WebhookUrlValidator classified a push notification webhook host in two places that did not agree. A host written as an IP literal was matched against a list of string prefixes that named the IPv6 unique local range fc00::/7, while a host reached through a name was resolved and the resulting address classified with the InetAddress predicates isLoopbackAddress, isAnyLocalAddress, isLinkLocalAddress and isSiteLocalAddress. Those predicates do not cover the same ground as the prefix list: isSiteLocalAddress reports the deprecated fec0::/10 block and not the fc00::/7 unique local addresses that replaced it, and the JDK carries no predicate for them at all. The same address was therefore accepted or rejected depending on how it was written, and a webhook URL whose host name resolved into fc00::/7 passed a guard that refused the identical address given as a literal. PushNotificationDispatcher then sent the push notification to that address, together with any Authorization header carried in the same configuration, whose scheme and credentials the registering caller supplies. The webhook URL arrives as TaskPushNotificationConfig.url from the caller registering the push notification, so it is attacker-controlled, and allowLocalWebhookUrls is false by default, which is the configuration in which the guard is expected to hold. The response is not relayed back to the caller who registered the configuration, so what the gap yields is a blind outbound HTTPS request from the Camel process to an internal address the guard was written to refuse; reaching a service that way additionally requires that the name resolve into fc00::/7 in the target environment, that an HTTPS service be listening on that address, and that the TLS handshake succeed for the name being requested, which is why the severity is assessed medium. The same string pre-check was also wrong in the other direction: it matched the raw host string without first establishing that the host was an IP literal, so any name merely beginning with fc or fd, such as fcm.googleapis.com, was refused outright.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. The 4.21.x release line reached end of life before this issue was resolved and will not receive a fix, so deployments on it must move to a supported release. Both the literal and the resolved path now classify the address from its raw bytes with one shared classifier, which recognises fc00::/7 and the shared address space 100.64.0.0/10, as well as IPv4-compatible, NAT64 (64:ff9b::/96) and 6to4 (2002::/16) addresses whose embedded IPv4 address is not globally routable. For deployments that cannot upgrade immediately, place authentication in front of the A2A push notification configuration path so that the webhook URL does not arrive from an untrusted caller, and deny egress from the Camel process to fc00::/7 at the network level; where the deployment has no need of IPv6, starting the JVM with -Djava.net.preferIPv4Stack=true removes the address class the gap turns on. Note that allowLocalWebhookUrls=false is already the default and does not by itself close the gap.
A broken access control vulnerability exists in the Foxit official website’s HTML-to-PDF conversion service due to the use of a shared token for submitted conversion documents. This may allow unauthorized users to access documents submitted by other users.
A server-side request forgery (SSRF) vulnerability exists in the Foxit official website’s HTML-to-PDF conversion service. Support for ZIP-formatted input can bypass restrictions on requests to internal IP addresses, potentially allowing discovery of internal network resources.
A denial of service vulnerability exists in github.com/go-jose/go-jose/v4 where parsing deeply nested JSON structures can cause the Go runtime to hit its stack limit and crash the application. This affects versions prior to 4.1.5 and up to 3.0.5. The issue is fixed in version 4.1.5. Applications parsing untrusted JSON with affected versions are exposed to crashes.
A denial of service vulnerability exists in github.com/go-jose/go-jose/v4 when decrypting ciphertexts using the CBC-HMAC content encryption algorithms A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512. Insufficient validation of parameters can cause a panic due to indexing into an empty buffer on untrusted input. This affects versions prior to 4.1.5 and up to 3.0.5. A fix is available in version 4.1.5.
### Impact
An attacker who controls the Grid configuration can set `credits.href` to a `javascript:` URL. The value is not validated against an allowed-scheme list before it is applied to the credits link, so activating that link runs attacker-supplied script in the origin of the page hosting the Grid. Exploitation requires that untrusted data reach the Grid configuration and that a user activate the credits link. Script running this way has the same access to page data, storage and session state as the hosting application.
### Workarounds
Paste in after the Grid Pro module is imported, before a Grid is created.
```javascript
const { AST } = Grid;
function sanitize(options) {
const credits = options && options.credits;
if (credits && typeof credits.href === 'string') {
const filtered = AST.filterUserAttributes({ href: credits.href });
if (!filtered.href) {
delete credits.href;
}
}
return options;
}
// Both Grid.grid() and grid.update() funnel through loadUserOptions, so one
// hook covers both entry points.
const { prototype } = Grid.Grid;
const loadUserOptions = prototype.loadUserOptions;
prototype.loadUserOptions = function (options, ...rest) {
sanitize(options);
return loadUserOptions.call(this, options, ...rest);
};
```
### Obtaining the patched version
The patched releases are available from all the usual distribution channels. With npm, upgrade the affected package to the patched version listed above, for example `npm install @highcharts/grid-lite@3.2.0`. If you load Highcharts Grid from a CDN, use a versioned URL, for example `https://cdn.jsdelivr.net/npm/@highcharts/grid-lite@3.2.0/grid-lite.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/grid/installation).
### Impact
The pagination language strings are written into the DOM as markup rather than as text. An attacker who controls those language options can supply elements carrying event handlers, and those handlers execute in the origin of the page hosting the Grid when the pagination controls render. Exploitation requires that untrusted data reach the Grid language configuration and that pagination be enabled on the Grid.
### Workarounds
Run this once after loading the Grid, before creating any grid:
```javascript
{
const Pagination = Grid.Pagination;
const escapeLang = (pagination) => {
const lang = pagination.lang;
if (!lang) {
return;
}
for (const key of ['pageInfo', 'pageSizeLabel']) {
if (typeof lang[key] === 'string') {
lang[key] = lang[key].replace(/</g, '<');
}
}
};
for (const name of ['updatePageInfo', 'renderPageSizeSelector']) {
const original = Pagination.prototype[name];
Pagination.prototype[name] = function (...args) {
escapeLang(this);
return original.apply(this, args);
};
}
}
```
### Obtaining the patched version
The patched releases are available from all the usual distribution channels. With npm, upgrade the affected package to the patched version listed above, for example `npm install @highcharts/grid-lite@3.2.0`. If you load Highcharts Grid from a CDN, use a versioned URL, for example `https://cdn.jsdelivr.net/npm/@highcharts/grid-lite@3.2.0/grid-lite.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/grid/installation).
### Impact
The edit mode fullscreen labels are parsed as HTML when the corresponding control is rendered. An attacker who controls the Dashboards language options can supply markup carrying event handlers, which then execute in the origin of the page hosting the dashboard. Exploitation requires that untrusted data reach the Dashboards language configuration and that the affected control be rendered. Script running this way has the same access to page data, storage and session state as the hosting application.
### Workarounds
Until you can upgrade, replace `Fullscreen.prototype.setButtonText` atapplication startup. The replacement is the original method with `textContent` in place of `innerHTML`.
#### If you install Dashboards from npm
Import the module once, before any board is created.
```js
import Fullscreen from '@highcharts/dashboards/es-modules/Dashboards/EditMode/Fullscreen.js';
Fullscreen.prototype.setButtonText = function () {
const editMode = this.board.editMode,
button = editMode?.tools.contextMenu?.items.viewFullscreen;
if (button?.innerElement) {
const lang = editMode.lang;
button.innerElement.textContent =
(this.isOpen ? lang.exitFullscreen : lang.viewFullscreen) || '';
}
};
```
#### If you load Dashboards from a `<script>` tag
The same replacement, taking `Fullscreen` from the global namespace. It must run after `modules/layout` and before any board is created.
```html
<script src="https://code.highcharts.com/dashboards/dashboards.js"></script>
<script src="https://code.highcharts.com/dashboards/modules/layout.js"></script>
<script>
{
const Fullscreen = window.Dashboards?.Fullscreen;
Fullscreen.prototype.setButtonText = function () {
const editMode = this.board.editMode,
button = editMode?.tools.contextMenu?.items.viewFullscreen;
if (button?.innerElement) {
const lang = editMode.lang;
button.innerElement.textContent =
(this.isOpen ? lang.exitFullscreen : lang.viewFullscreen) || '';
}
};
}
</script>
```
If your application does not need Edit Mode, leaving it disabled (`editMode.enabled: false`) removes the exposure as well. The same applies to the context menu — the label is only reachable when `viewFullscreen` is among `editMode.contextMenu.items`.
### Obtaining the patched version
The patched releases are available from all the usual distribution channels. With npm, upgrade the affected package to the patched version listed above, for example `npm install @highcharts/dashboards@4.2.3`. If you load Highcharts Dashboards from a CDN, use a versioned URL, for example `https://code.highcharts.com/dashboards/4.2.3/dashboards.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/dashboards/installation).
### Impact
The component language strings shown in the edit mode sidebar are parsed as HTML rather than inserted as text. An attacker who controls those language options can supply markup carrying event handlers, which execute in the origin of the page hosting the dashboard once the sidebar renders the affected labels. Exploitation requires that untrusted data reach the Dashboards language configuration and that a user open the edit mode sidebar.
### Workarounds
Until you can upgrade, patch `EditMode` once at application startup. The hook runs before the sidebar is built, so the labels are already harmless by the time they are rendered. Assigning a string to `textContent` and reading back `innerHTML` turns any markup into literal text, which is exactly what the fixed version renders.
After importing the module, use this code snipped once, before any board is created.
```js
{
const EditMode = window.Dashboards?.EditMode;
const escapeHTML = (text) => text
.replace(/&/g, '&')
.replace(/</g, '<')
.replace(/>/g, '>');
const patched = new WeakSet();
const originalInit = EditMode.prototype.init;
EditMode.prototype.init = function (...args) {
const labels = this.lang?.sidebar;
if (labels && !patched.has(this)) {
patched.add(this);
for (const key of Object.keys(labels)) {
if (typeof labels[key] === 'string') {
labels[key] = escapeHTML(labels[key]);
}
}
}
return originalInit.apply(this, args);
};
}
```
If your application does not need Edit Mode, leaving it disabled (`editMode.enabled: false`) removes the exposure as well.
### Obtaining the patched version
The patched releases are available from all the usual distribution channels. With npm, upgrade the affected package to the patched version listed above, for example `npm install @highcharts/dashboards@4.2.3`. If you load Highcharts Dashboards from a CDN, use a versioned URL, for example `https://code.highcharts.com/dashboards/4.2.3/dashboards.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/dashboards/installation).
### Impact
A `credits.href` value beginning with `javascript:` is assigned to the window location when the credits label is clicked, without being checked against an allowed-scheme list. An attacker who controls the chart configuration can therefore run script in the origin of the page hosting the chart. Exploitation requires that untrusted data reach the chart configuration and that a user click the credits label. Charts built with Highcharts Stock, Maps and Gantt are included, since those ship from the same package as Core.
### Workarounds
Drop-in fix - for any versions affected (5.0.0-13.0.2).
Add the below IIFE to run after Highcharts is loaded, but before a chart is created.
```js
!function(t){if(t&&t.Chart&&!t.Chart.prototype.creditsHrefPatched){var r=t.Chart.prototype,e=r.addCredits;r.addCredits=function(n){var o=t.merge(!0,this.options.credits,n);return o&&o.href&&!c(o.href)&&delete o.href,e.call(this,o)},r.creditsHrefPatched=!0}function c(r){var e=t.AST&&t.AST.allowedReferences||["https://","http://","mailto:","/","../","./","#"];return"string"==typeof r&&e.some(function(t){return 0===r.indexOf(t)})}}(Highcharts);
```
[Live demo & testing](https://jsfiddle.net/BlackLabel/6a09ws1f/)
### Obtaining the patched version
The patched releases are available from all the usual distribution channels. With npm, upgrade the affected package to the patched version listed above, for example `npm install highcharts@ 13.1.0`. If you load Highcharts from the CDN, use the versioned URLs on code.highcharts.com, for example `https://code.highcharts.com/13.1.0/highcharts.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/getting-started/installation).
### Impact
A dot-separated key path taken from `series.keys` is followed without filtering the individual segments. An attacker who controls `series.keys` and the matching point data can use a path such as `__proto__.polluted` to set arbitrary properties on `Object.prototype`. The resulting properties are visible to all JavaScript running in the page, not only to the chart. No user interaction is required beyond rendering the chart.
The injected properties are inert until other code on the page reads them, so consequences depend on the consuming application.
### Workarounds
Drop-in fix - for any versions affected (6.1.0-13.0.2). Add the below IIFE to run after Highcharts is loaded.
```javascript
((H)=>{const X = H.isObject;H.Point.prototype.setNestedProperty = function setNestedProperty(t,e,i){let s=i.split(".");return s.some(t=>"__proto__"===t||"constructor"===t)||s.reduce(function(t,i,s,o){let r=o.length-1===s;return t[i]=r?e:X(t[i],!0)?t[i]:{},t[i]},t),t};})(Highcharts);
```
[Live demo & testing](https://jsfiddle.net/BlackLabel/z3rbtm7u/)
### Obtaining the patched version
The patched releases are available from all the usual distribution channels. With npm, upgrade the affected package to the patched version listed above, for example `npm install highcharts@13.1.1`. If you load Highcharts from the CDN, use the versioned URLs on code.highcharts.com, for example `https://code.highcharts.com/13.1.1/highcharts.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/getting-started/installation).