![]() |
Description: Impact
What kind of vulnerability is it? Who is impacted?
Remote code execution is possible in web-accessible installations of hypercube.
Patches
Has the problem been patched? What versions should users upgrade to?
Not yet, though no patch is neccessary if your installation of the microservices is behind a firewall. See below.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
The exploit requires making a request against Hypercube's endpoints; therefore, the ability to make use of the exploit is much reduced if the microservice is not directly accessible from the Internet, so: Prevent general access from the Internet from hitting Hypercube. Furthermore, if you've used any of the official installation methods, your Crayfish will be behind a firewall and there is no work neccessary.
The webserver might be made to validate the structure of headers passed, but that would only be neccessary if you publicly exposed the endpoint. Standard security practices should be applied.
References
Are there any links users can visit to find out more?
XBOW-024-074
References
https://github.com/Islandora/Crayfish/security/advisories/GHSA-c2p2-hgjg-9r3f
https://github.com/advisories/GHSA-c2p2-hgjg-9r3f
February 12th, 2025 (5 months ago)
|
![]() |
February 12th, 2025 (5 months ago)
|
![]() |
February 12th, 2025 (5 months ago)
|
CVE-2025-25184 |
Description: Summary
Rack::CommonLogger can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs.
Details
When a user provides the authorization credentials via Rack::Auth::Basic, if success, the username will be put in env['REMOTE_USER'] and later be used by Rack::CommonLogger for logging purposes.
The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile.
Impact
Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files.
Mitigation
Update to the latest version of Rack.
References
https://github.com/rack/rack/security/advisories/GHSA-7g2v-jj9q-g3rg
https://nvd.nist.gov/vuln/detail/CVE-2025-25184
https://github.com/rack/rack/commit/074ae244430cda05c27ca91cda699709cfb3ad8e
https://github.com/advisories/GHSA-7g2v-jj9q-g3rg
EPSS Score: 0.04%
February 12th, 2025 (5 months ago)
|
CVE-2025-25199 |
Description: Calls to cng.TLS1PRF don't release the key handle, producing a small memory leak every time.
References
https://github.com/microsoft/go-crypto-winnative/security/advisories/GHSA-29c6-3hcj-89cf
https://nvd.nist.gov/vuln/detail/CVE-2025-25199
https://github.com/microsoft/go-crypto-winnative/commit/f49c8e1379ea4b147d5bff1b3be5b0ff45792e41
https://github.com/advisories/GHSA-29c6-3hcj-89cf
EPSS Score: 0.04%
February 12th, 2025 (5 months ago)
|
CVE-2025-1243 |
Description: The Temporal api-go library prior to version 1.44.1 did not send update response information to Data Converter when the proxy package within the api-go module was used in a gRPC proxy prior to transmission. This resulted in information contained within the update response field not having Data Converter transformations (e.g. encryption) applied. This is an issue only when using the UpdateWorkflowExecution APIs (released on 13th January 2025) with a proxy leveraging the api-go library before version 1.44.1.
Other data fields were correctly sent to Data Converter. This issue does not impact the Data Converter server. Data was encrypted in transit. Temporal Cloud services are not impacted.
References
https://nvd.nist.gov/vuln/detail/CVE-2025-1243
https://github.com/temporalio/api-go/releases/tag/v1.44.1
https://temporal.io/blog/announcing-a-new-operation-workflow-update
https://github.com/temporalio/api-go/commit/dad8b169ada911d3778e070484d1ae78a58bd22b
https://github.com/advisories/GHSA-q9w6-cwj4-gf4p
CVSS: LOW (2.0) EPSS Score: 0.04%
February 12th, 2025 (5 months ago)
|
CVE-2025-25200 |
Description: Summary
Koa uses an evil regex to parse the X-Forwarded-Proto and X-Forwarded-Host HTTP headers. This can be exploited to carry out a Denial-of-Service attack.
PoC
Coming soon.
Impact
This is a Regex Denial-of-Service attack and causes memory exhaustion. The regex should be improved and empty values should not be allowed.
References
https://github.com/koajs/koa/security/advisories/GHSA-593f-38f6-jp5m
https://nvd.nist.gov/vuln/detail/CVE-2025-25200
https://github.com/koajs/koa/commit/5054af6e31ffd451a4151a1fe144cef6e5d0d83c
https://github.com/koajs/koa/commit/5f294bb1c7c8d9c61904378d250439a321bffd32
https://github.com/koajs/koa/commit/93fe903fc966635a991bcf890cfc3427d33a1a08
https://github.com/koajs/koa/releases/tag/2.15.4
https://github.com/advisories/GHSA-593f-38f6-jp5m
CVSS: CRITICAL (9.2) EPSS Score: 0.04%
February 12th, 2025 (5 months ago)
|
![]() |
Description: Summary
This report finds 2 availability issues due to the regex used in the parse-duration npm package:
An event loop delay due to the CPU-bound operation of resolving the provided string, from a 0.5ms and up to ~50ms per one operation, with a varying size from 0.01 MB and up to 4.3 MB respectively.
An out of memory that would crash a running Node.js application due to a string size of roughly 10 MB that utilizes unicode characters.
PoC
Refer to the following proof of concept code that provides a test case and makes use of the regular expression in the library as its test case to match against strings:
// Vulnerable regex to use from the library:
import parse from './index.js'
function generateStressTestString(length, decimalProbability) {
let result = "";
for (let i = 0; i < length; i++) {
if (Math.random() < decimalProbability) {
result += "....".repeat(99);
}
result += Math.floor(Math.random() * 10);
}
return result;
}
function getStringSizeInMB_UTF8(str) {
const sizeInBytes = Buffer.byteLength(str, 'utf8');
const sizeInMB = sizeInBytes / (1024 * 1024);
return sizeInMB;
}
// Generate test strings with varying length and decimal probability:
const longString1 = generateStressTestString(380, 0.05);
const longString2 = generateStressTestString(10000, 0.9);
const longString3 = generateStressTestString(500000, 1);
const longStringVar1 = '-1e' + '-----'.repeat(915000)
const longStringVar2 = "1" + "0".repeat(500) + "e1" + "α".repeat(52250...
February 12th, 2025 (5 months ago)
|
![]() |
[elliptic] Elliptic's private key extraction in ECDSA upon signing a malformed input (e.g. a string)
Description: Summary
Private key can be extracted from ECDSA signature upon signing a malformed input (e.g. a string or a number), which could e.g. come from JSON network input
Note that elliptic by design accepts hex strings as one of the possible input types
Details
In this code: https://github.com/indutny/elliptic/blob/3e46a48fdd2ef2f89593e5e058d85530578c9761/lib/elliptic/ec/index.js#L100-L107
msg is a BN instance after conversion, but nonce is an array, and different BN instances could generate equivalent arrays after conversion.
Meaning that a same nonce could be generated for different messages used in signing process, leading to k reuse, leading to private key extraction from a pair of signatures
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
PoC
k reuse example
import elliptic from 'elliptic'
const { ec: EC } = elliptic
const privateKey = crypto.getRandomValues(new Uint8Array(32))
const curve = 'ed25519' // or any other curve, e.g. secp256k1
const ec = new EC(curve)
const pret...
February 12th, 2025 (5 months ago)
|
CVE-2024-57000 |
Description: An issue in Anyscale Inc Ray between v.2.9.3 and v.2.40.0 allows a remote attacker to execute arbitrary code via a crafted script.
References
https://nvd.nist.gov/vuln/detail/CVE-2024-57000
https://github.com/honysyang/Ray.git
https://github.com/advisories/GHSA-xg2h-7cxj-3gvh
EPSS Score: 0.04%
February 12th, 2025 (5 months ago)
|