CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!
Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
CVE-2025-52898 |
Description: Frappe is a full-stack web application framework. Prior to versions 14.94.3 and 15.58.0, a carefully crafted request could lead to a malicious actor getting access to a user's password reset token. This can only be exploited on self hosted instances configured in a certain way. Frappe Cloud users are safe. This issue has been patched in versions 14.94.3 and 15.58.0. Workarounds for this issue involve verifying password reset URLs before clicking on them or upgrading for self hosted users.
CVSS: HIGH (8.7)
June 30th, 2025 (about 7 hours ago)
|
|
CVE-2025-52896 |
Description: Frappe is a full-stack web application framework. Prior to versions 14.94.2 and 15.57.0, authenticated users could upload carefully crafted malicious files via Data Import, leading to cross-site scripting (XSS). This issue has been patched in versions 14.94.2 and 15.57.0. There are no workarounds for this issue other than upgrading.
CVSS: HIGH (8.6)
June 30th, 2025 (about 7 hours ago)
|
|
CVE-2025-52895 |
Description: Frappe is a full-stack web application framework. Prior to versions 14.94.3 and 15.58.0, SQL injection could be achieved via a specially crafted request, which could allow malicious person to gain access to sensitive information. This issue has been patched in versions 14.94.3 and 15.58.0. There are no workarounds for this issue other than upgrading.
CVSS: HIGH (8.7)
June 30th, 2025 (about 7 hours ago)
|
|
CVE-2025-45931 |
Description: An issue D-Link DIR-816-A2 DIR-816A2_FWv1.10CNB05_R1B011D88210 allows a remote attacker to execute arbitrary code via system() function in the bin/goahead file
June 30th, 2025 (about 7 hours ago)
|
|
CVE-2025-45143 |
Description: string-math v1.2.2 was discovered to contain a Regex Denial of Service (ReDoS) which is exploited via a crafted input.
June 30th, 2025 (about 7 hours ago)
|
|
Description: The Berlin Commissioner for Data Protection has formally requested Google and Apple to remove the DeepSeek AI application from the application stores due to GDPR violations. [...]
June 30th, 2025 (about 7 hours ago)
|
|
Description: Summary
Private key can be extracted on signing a malicious JSON-stringifiable object, when global Buffer is buffer package
Details
This affects only environments where require('buffer') is https://npmjs.com/buffer
E.g.: browser bundles, React Native apps, etc.
Buffer.isBuffer check can be bypassed, resulting in k reuse for different messages, leading to private key extraction over a single invalid message (and a second one for which any message/signature could be taken, e.g. previously known valid one)
v2.x is unaffected as it verifies input to be an actual Uint8Array instance
Such a message can be constructed for any already known message/signature pair, meaning that the attack needs only a single malicious message being signed for a full key extraction
While signing unverified attacker-controlled messages would be problematic itself (and exploitation of this needs such a scenario), signing a single message still should not leak the private key
Also, message validation could have the same bug (out of scope for this report, but could be possible in some situations), which makes this attack more likely when used in a chain
https://github.com/bitcoinjs/tiny-secp256k1/pull/140 is a subtle fix for this
PoC
This code deliberately doesn't provide funnyBuffer and extractTiny for now, could be updated later
import secp256k1 from 'tiny-secp256k1'
import crypto from 'crypto'
const key = crypto.randomBytes(32)
const msg0 = crypto.randomBytes(32)
const sig0 = secp256k1.sign(msg0, k...
June 30th, 2025 (about 7 hours ago)
|
|
|
Description: Summary
A malicious JSON-stringifyable message can be made passing on verify(), when global Buffer is buffer package
Details
This affects only environments where require('buffer') is https://npmjs.com/buffer
E.g.: browser bundles, React Native apps, etc.
Buffer.isBuffer check can be bypassed, resulting in strange objects being accepted as message, and those messages could trick verify() into returning false-positive true values
v2.x is unaffected as it verifies input to be an actual Uint8Array instance
Such a message can be constructed for any already known message/signature pair
There are some restrictions though (also depending on the known message/signature), but not very limiting, see PoC for example
https://github.com/bitcoinjs/tiny-secp256k1/pull/140 is a subtle fix for this
PoC
This code deliberately doesn't provide reencode for now, could be updated later
import { randomBytes } from 'crypto'
import tiny from 'tiny-secp256k1' // 1.1.6
// Random keypair
const privateKey = randomBytes(32)
const publicKey = tiny.pointFromScalar(privateKey)
const valid = Buffer.alloc(32).fill(255) // let's sign a static buffer
const signature = tiny.sign(valid, privateKey)
// Prevent processing any unverified data by fail-closed throwing
function verified(data, signature) {
if (!Buffer.isBuffer(data)) data = Buffer.from(data, 'hex')
if (!tiny.verify(data, publicKey, signature)) throw new Error('Signature invalid!')
return new Uint8Array(data)
}
function safeProcess(payload) {
...
June 30th, 2025 (about 7 hours ago)
|
|
|
Description: electron's ASAR Integrity can be bypass by modifying the content.
Impact
This only impacts apps that have the embeddedAsarIntegrityValidation and onlyLoadAppFromAsar fuses enabled. Apps without these fuses enabled are not impacted. This issue is specific to Windows, apps using these fuses on macOS are unimpacted.
Specifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the .app bundle on macOS which these fuses are supposed to protect against.
Workarounds
There are no app side workarounds, you must update to a patched version of Electron.
Fixed Versions
30.0.5
31.0.0-beta.1
For more information
If you have any questions or comments about this advisory, email us at [email protected]
References
https://github.com/electron/electron/security/advisories/GHSA-xw5q-g62x-2qjc
https://github.com/advisories/GHSA-xw5q-g62x-2qjc
June 30th, 2025 (about 7 hours ago)
|
|
|
Description: Summary
URLs that are accessed by a user are commonly logged in many locations, both server- and client-side. It is thus good practice to never transmit any secret information as part of a URL. The Filebrowser violates this practice, since access tokens are used as GET parameters.
Impact
The JSON Web Token (JWT) which is used as a session identifier will get leaked to anyone having access to the URLs accessed by the user. This will give the attacker full access to the user's account and, in consequence, to all sensitive files the user has access to.
Description
Sensitive information in URLs is logged by several components (see the following examples), even if access is protected by TLS.
The browser history
The access logs on the affected web server
Proxy servers or reverse proxy servers
Third-party servers via the HTTP referrer header
In case attackers can access certain logs, they could read the included sensitive data.
Proof of Concept
When a file is downloaded via the web interface, the JWT is part of the URL:
GET /api/raw/testdir/testfile.txt?auth=eyJh[...]_r4EQ HTTP/1.1
Host: filebrowser.local:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: http://filebrowser.local:8080/files/testdir/
Cookie: auth=eyJh[...]_r4EQ
Upgrade-Insecure-Requests: 1
Priority: u=0, i
...
June 30th, 2025 (about 7 hours ago)
|