deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-22157
Published: 2025-05-20
Description: This High severity PrivEsc (Privilege Escalation) vulnerability was introduced in versions:

9.12.0, 10.3.0, 10.4.0, and 10.5.0 of Jira Core Data Center and Server

5.12.0, 10.3.0, 10.4.0, and 10.5.0 of Jira Service Management Data Center and Server

This PrivEsc (Privilege Escalation) vulnerability, with a CVSS Score of 7.2, allows an attacker to perform actions as a higher-privileged user. 

Atlassian recommends that Jira Core Data Center and Server and Jira Service Management Data Center and Server customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions:

Jira Core Data Center and Server 9.12: Upgrade to a release greater than or equal to 9.12.20

Jira Service Management Data Center and Server 5.12: Upgrade to a release greater than or equal to 5.12.20

Jira Core Data Center 10.3: Upgrade to a release greater than or equal to 10.3.5

Jira Service Management Data Center 10.3: Upgrade to a release greater than or equal to 10.3.5

Jira Core Data Center 10.4: Upgrade to a release greater than or equal to 10.6.0

Jira Service Management Data Center 10.4: Upgrade to a release greater than or equal to 10.6.0

Jira Core Data Center 10.5: Upgrade to a release greater than or equal to 10.5.1

Jira Service Management Data Center 10.5: Upgrade to a release greater than or equal to 10.5.1

See the release notes. You can download the latest version of Jira Core Data Center and Jira Service Management Data Center from the download center. 

This vulnerability was reported via our Atlassian (Internal) program.
CVSS Score: 8.8 (HIGH)
CWE: CWE-284
References: https://confluence.atlassian.com/pages/viewpage.action?pageId=[PII_REDACTED]; https://jira.atlassian.com/browse/JRASERVER-78766; https://jira.atlassian.com/browse/JSDSERVER-16206
CVE: CVE-2025-37983
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

qibfs: fix _another_ leak

failure to allocate inode => leaked dentry...

this one had been there since the initial merge; to be fair,
if we are that far OOM, the odds of failing at that particular
allocation are low...
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/24faa6ea274a2b96d0a78a0996c3137c2b2a65f0; https://git.kernel.org/stable/c/3c2fde33e3e505dfd1a895d1f24bad650c655e14; https://git.kernel.org/stable/c/47ab2caba495c1d6a899d284e541a8df656dcfe9
CVE: CVE-2025-37984
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()

Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa
implementation's ->key_size() callback returns an unusually large value.
Herbert instead suggests (for a division by 8):

  X / 8 + !!(X & 7)

Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and
use it in lieu of DIV_ROUND_UP() for ->key_size() return values.

Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes"
parameter is a ->key_size() return value in some instances, or a
user-specified ASN.1 length in the case of ecdsa_get_signature_rs().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/921b8167f10708e38080f84e195cdc68a7a561f1; https://git.kernel.org/stable/c/b16510a530d1e6ab9683f04f8fb34f2e0f538275; https://git.kernel.org/stable/c/f02f0218be412cff1c844addf58e002071be298b
CVE: CVE-2025-37985
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: wdm: close race between wdm_open and wdm_wwan_port_stop

Clearing WDM_WWAN_IN_USE must be the last action or
we can open a chardev whose URBs are still poisoned
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/217fe1fc7d112595a793e02b306710e702eac492; https://git.kernel.org/stable/c/52ae15c665b5fe5876655aaccc3ef70560b0e314; https://git.kernel.org/stable/c/54f7f8978af19f899dec80bcc71c8d4855dfbd72
CVE: CVE-2025-37986
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: typec: class: Invalidate USB device pointers on partner unregistration

To avoid using invalid USB device pointers after a Type-C partner
disconnects, this patch clears the pointers upon partner unregistration.
This ensures a clean state for future connections.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/40966fc9939e85677fdb489dfddfa205baaad03b; https://git.kernel.org/stable/c/66e1a887273c6b89f09bc11a40d0a71d5a081a8e; https://git.kernel.org/stable/c/74911338f47c13d1b9470fc50718182bffad42e2
CVE: CVE-2025-37987
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

pds_core: Prevent possible adminq overflow/stuck condition

The pds_core's adminq is protected by the adminq_lock, which prevents
more than 1 command to be posted onto it at any one time. This makes it
so the client drivers cannot simultaneously post adminq commands.
However, the completions happen in a different context, which means
multiple adminq commands can be posted sequentially and all waiting
on completion.

On the FW side, the backing adminq request queue is only 16 entries
long and the retry mechanism and/or overflow/stuck prevention is
lacking. This can cause the adminq to get stuck, so commands are no
longer processed and completions are no longer sent by the FW.

As an initial fix, prevent more than 16 outstanding adminq commands so
there's no way to cause the adminq from getting stuck. This works
because the backing adminq request queue will never have more than 16
pending adminq commands, so it will never overflow. This is done by
reducing the adminq depth to 16.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2982e07ad72b48eb12c29a87a3f2126ea552688c; https://git.kernel.org/stable/c/517f928cc0c133472618cbba18382b46f5f71ba3; https://git.kernel.org/stable/c/5e3dc65675faad846420d24762e4faadc12d9392
CVE: CVE-2025-37988
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()

Normally do_lock_mount(path, _) is locking a mountpoint pinned by
*path and at the time when matching unlock_mount() unlocks that
location it is still pinned by the same thing.

Unfortunately, for 'beneath' case it's no longer that simple -
the object being locked is not the one *path points to.  It's the
mountpoint of path->mnt.  The thing is, without sufficient locking
->mnt_parent may change under us and none of the locks are held
at that point.  The rules are
	* mount_lock stabilizes m->mnt_parent for any mount m.
	* namespace_sem stabilizes m->mnt_parent, provided that
m is mounted.
	* if either of the above holds and refcount of m is positive,
we are guaranteed the same for refcount of m->mnt_parent.

namespace_sem nests inside inode_lock(), so do_lock_mount() has
to take inode_lock() before grabbing namespace_sem.  It does
recheck that path->mnt is still mounted in the same place after
getting namespace_sem, and it does take care to pin the dentry.
It is needed, since otherwise we might end up with racing mount --move
(or umount) happening while we were getting locks; in that case
dentry would no longer be a mountpoint and could've been evicted
on memory pressure along with its inode - not something you want
when grabbing lock on that inode.

However, pinning a dentry is not enough - the matching mount is
also pinned only by the fact that path->mnt is mounted on top it
and at that point we are not holding any locks whatsoever, so
the same kind of races could end up with all references to
that mount gone just as we are about to enter inode_lock().
If that happens, we are left with filesystem being shut down while
we are holding a dentry reference on it; results are not pretty.

What we need to do is grab both dentry and mount at the same time;
that makes inode_lock() safe *and* avoids the problem with fs getting
shut down under us.  After taking namespace_sem we verify that
path->mnt is still mounted (which stabilizes its ->mnt_parent) and
check that it's still mounted at the same place.  From that point
on to the matching namespace_unlock() we are guaranteed that
mount/dentry pair we'd grabbed are also pinned by being the mountpoint
of path->mnt, so we can quietly drop both the dentry reference (as
the current code does) and mnt one - it's OK to do under namespace_sem,
since we are not dropping the final refs.

That solves the problem on do_lock_mount() side; unlock_mount()
also has one, since dentry is guaranteed to stay pinned only until
the namespace_unlock().  That's easy to fix - just have inode_unlock()
done earlier, while it's still pinned by mp->m_dentry.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0d039eac6e5950f9d1ecc9e410c2fd1feaeab3b6; https://git.kernel.org/stable/c/4f435c1f4c48ff84968e2d9159f6fa41f46cf998; https://git.kernel.org/stable/c/a61afd54826ac24c2c93845c4f441dbc344875b1
CVE: CVE-2025-37989
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

net: phy: leds: fix memory leak

A network restart test on a router led to an out-of-memory condition,
which was traced to a memory leak in the PHY LED trigger code.

The root cause is misuse of the devm API. The registration function
(phy_led_triggers_register) is called from phy_attach_direct, not
phy_probe, and the unregister function (phy_led_triggers_unregister)
is called from phy_detach, not phy_remove. This means the register and
unregister functions can be called multiple times for the same PHY
device, but devm-allocated memory is not freed until the driver is
unbound.

This also prevents kmemleak from detecting the leak, as the devm API
internally stores the allocated pointer.

Fix this by replacing devm_kzalloc/devm_kcalloc with standard
kzalloc/kcalloc, and add the corresponding kfree calls in the unregister
path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/41143e71052a00d654c15dc924fda50c1e7357d0; https://git.kernel.org/stable/c/618541a6cc1511064dfa58c89b3445e21844092f; https://git.kernel.org/stable/c/663c3da86e807c6c07ed48f911c7526fad6fe1ff
CVE: CVE-2025-37990
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()

The function brcmf_usb_dl_writeimage() calls the function
brcmf_usb_dl_cmd() but dose not check its return value. The
'state.state' and the 'state.bytes' are uninitialized if the
function brcmf_usb_dl_cmd() fails. It is dangerous to use
uninitialized variables in the conditions.

Add error handling for brcmf_usb_dl_cmd() to jump to error
handling path if the brcmf_usb_dl_cmd() fails and the
'state.state' and the 'state.bytes' are uninitialized.

Improve the error message to report more detailed error
information.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/08424a0922fb9e32a19b09d852ee87fb6c497538; https://git.kernel.org/stable/c/508be7c001437bacad7b9a43f08a723887bcd1ea; https://git.kernel.org/stable/c/524b70441baba453b193c418e3142bd31059cc1f
CVE: CVE-2025-37991
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

parisc: Fix double SIGFPE crash

Camm noticed that on parisc a SIGFPE exception will crash an application with
a second SIGFPE in the signal handler.  Dave analyzed it, and it happens
because glibc uses a double-word floating-point store to atomically update
function descriptors. As a result of lazy binding, we hit a floating-point
store in fpe_func almost immediately.

When the T bit is set, an assist exception trap occurs when when the
co-processor encounters *any* floating-point instruction except for a double
store of register %fr0.  The latter cancels all pending traps.  Let's fix this
by clearing the Trap (T) bit in the FP status register before returning to the
signal handler in userspace.

The issue can be reproduced with this test program:

root@parisc:~# cat fpe.c

static void fpe_func(int sig, siginfo_t *i, void *v) {
        sigset_t set;
        sigemptyset(&set);
        sigaddset(&set, SIGFPE);
        sigprocmask(SIG_UNBLOCK, &set, NULL);
        printf("GOT signal %d with si_code %ld\n", sig, i->si_code);
}

int main() {
        struct sigaction action = {
                .sa_sigaction = fpe_func,
                .sa_flags = SA_RESTART|SA_SIGINFO };
        sigaction(SIGFPE, &action, 0);
        feenableexcept(FE_OVERFLOW);
        return printf("%lf\n",[PII_REDACTED]623158E308*[PII_REDACTED]623158E308);
}

root@parisc:~# gcc fpe.c -lm
root@parisc:~# ./a.out
 Floating point exception

root@parisc:~# strace -f ./a.out
 execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars */) = 0
 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
 ...
 rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---
 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---
 +++ killed by SIGFPE +++
 Floating point exception
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6; https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106; https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f
CVE: CVE-2025-46724
Published: 2025-05-20
Description: Langroid is a Python framework to build large language model (LLM)-powered applications. Prior to version 0.53.15, `TableChatAgent` uses `pandas eval()`. If fed by untrusted user input, like the case of a public-facing LLM application, it may be vulnerable to code injection. Langroid 0.53.15 sanitizes input to `TableChatAgent` by default to tackle the most common attack vectors, and added several warnings about the risky behavior in the project documentation.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-94
References: https://github.com/langroid/langroid/commit/0d9e4a7bb3ae2eef8d38f2e970ff916599a2b2a6; https://github.com/langroid/langroid/security/advisories/GHSA-jqq5-wc57-f8hj; https://github.com/langroid/langroid/security/advisories/GHSA-jqq5-wc57-f8hj
CVE: CVE-2025-46725
Published: 2025-05-20
Description: Langroid is a Python framework to build large language model (LLM)-powered applications. Prior to version 0.53.15, `LanceDocChatAgent` uses pandas eval() through `compute_from_docs()`. As a result, an attacker may be able to make the agent run malicious commands through `QueryPlan.dataframe_calc]`) compromising the host system. Langroid 0.53.15 sanitizes input to the affected function by default to tackle the most common attack vectors, and added several warnings about the risky behavior in the project documentation.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-94
References: https://github.com/langroid/langroid/commit/0d9e4a7bb3ae2eef8d38f2e970ff916599a2b2a6; https://github.com/langroid/langroid/security/advisories/GHSA-22c2-9gwg-mj59
CVE: CVE-2025-47277
Published: 2025-05-20
Description: vLLM, an inference and serving engine for large language models (LLMs), has an issue in versions 0.6.5 through 0.8.4 that ONLY impacts environments using the `PyNcclPipe` KV cache transfer integration with the V0 engine. No other configurations are affected. vLLM supports the use of the `PyNcclPipe` class to establish a peer-to-peer communication domain for data transmission between distributed nodes. The GPU-side KV-Cache transmission is implemented through the `PyNcclCommunicator` class, while CPU-side control message passing is handled via the `send_obj` and `recv_obj` methods on the CPU side.​ The intention was that this interface should only be exposed to a private network using the IP address specified by the `--kv-ip` CLI parameter. The vLLM documentation covers how this must be limited to a secured network. The default and intentional behavior from PyTorch is that the `TCPStore` interface listens on ALL interfaces, regardless of what IP address is provided. The IP address given was only used as a client-side address to use. vLLM was fixed to use a workaround to force the `TCPStore` instance to bind its socket to a specified private interface. As of version 0.8.5, vLLM limits the `TCPStore` socket to the private interface as configured.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-502
References: https://docs.vllm.ai/en/latest/deployment/security.html; https://github.com/vllm-project/vllm/commit/0d6e187e88874c39cda7409cf673f9e6546893e7; https://github.com/vllm-project/vllm/pull/15988
CVE: CVE-2025-47850
Published: 2025-05-20
Description: In JetBrains YouTrack before 2025.1.74704 restricted attachments could become visible after issue cloning
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-306
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-47851
Published: 2025-05-20
Description: In JetBrains TeamCity before 2025.03.2 stored XSS via GitHub Checks Webhook was possible
CVSS Score: 4.8 (MEDIUM)
CWE: CWE-79
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-47852
Published: 2025-05-20
Description: In JetBrains TeamCity before 2025.03.2 stored XSS via YouTrack integration was possible
CVSS Score: 4.8 (MEDIUM)
CWE: CWE-79
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-47853
Published: 2025-05-20
Description: In JetBrains TeamCity before 2025.03.2 stored XSS via Jira integration was possible
CVSS Score: 4.8 (MEDIUM)
CWE: CWE-79
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-47854
Published: 2025-05-20
Description: In JetBrains TeamCity before 2025.03.2 open redirect was possible on editing VCS Root page
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-601
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-48391
Published: 2025-05-20
Description: In JetBrains YouTrack before 2025.1.76253 deletion of issues was possible due to missing permission checks in API
CVSS Score: 7.7 (HIGH)
CWE: CWE-306
References: https://www.jetbrains.com/privacy-security/issues-fixed/
CVE: CVE-2025-4364
Published: 2025-05-20
Description: The affected products could allow an unauthenticated attacker to access system information that could enable further access to sensitive files and obtain administrative credentials.
CWE: CWE-497
References: https://www.cisa.gov/news-events/ics-advisories/icsa-25-140-11
CVE: CVE-2025-47290
Published: 2025-05-20
Description: containerd is a container runtime. A time-of-check to time-of-use (TOCTOU) vulnerability was found in containerd v2.1.0. While unpacking an image during an image pull, specially crafted container images could arbitrarily modify the host file system. The only affected version of containerd is 2.1.0.  Other versions of containerd are not affected. This bug has been fixed in containerd 2.1.1. Users should update to this version to resolve the issue. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.
CVSS Score: 5.9 (MEDIUM)
CWE: CWE-367
References: https://github.com/containerd/containerd/commit/cada13298fba85493badb6fecb6ccf80e49673cc; https://github.com/containerd/containerd/releases/tag/v2.1.1; https://github.com/containerd/containerd/security/advisories/GHSA-cm76-qm8v-3j95
CVE: CVE-2025-4996
Published: 2025-05-20
Description: A vulnerability, which was classified as problematic, has been found in Intelbras RF 301K 1.1.5. This issue affects some unknown processing of the component Add Static IP. The manipulation of the argument Description leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure.
CVSS Score: 2.4 (LOW)
CWE: CWE-79, CWE-94
References: https://vuldb.com/?ctiid.309647; https://vuldb.com/?id.309647; https://vuldb.com/?submit.501900
CVE: CVE-2025-44881
Published: 2025-05-20
Description: A command injection vulnerability in the component /cgi-bin/qos.cgi of Wavlink WL-WN579A3 v1.0 allows attackers to execute arbitrary commands via a crafted input.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-94
References: https://lafdrew.github.io/2025/03/31/Remote-Command-Execution-in-qos-cgi-of-wavlink-WL-WN579A3-Device/
CVE: CVE-2025-44884
Published: 2025-05-20
Description: FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the web_sys_infoContact_post function.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-121
References: https://lafdrew.github.io/2025/04/20/web-sys-infoContact-post-contact/
CVE: CVE-2025-44885
Published: 2025-05-20
Description: FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the remote_ip parameter in the web_snmpv3_remote_engineId_add_post function.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-121
References: https://lafdrew.github.io/2025/04/20/web-snmpv3-remote-engineId-add-post-remote-ip/
CVE: CVE-2025-44886
Published: 2025-05-20
Description: FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the byruleEditName parameter in the web_acl_mgmt_Rules_Edit_postcontains function.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-121
References: https://lafdrew.github.io/2025/04/20/web-acl-mgmt-Rules-Edit-post-ruleEditName/
CVE: CVE-2025-44887
Published: 2025-05-20
Description: FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the radIpkey parameter in the web_radiusSrv_post function.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-121
References: https://lafdrew.github.io/2025/04/20/web-radiusSrv-post-radIp/
CVE: CVE-2025-44888
Published: 2025-05-20
Description: FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the stp_conf_name parameter in the web_stp_globalSetting_post function.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-121
References: https://lafdrew.github.io/2025/04/20/web-stp-globalSetting-post-stp-conf-name/
CVE: CVE-2025-44890
Published: 2025-05-20
Description: FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the host_ip parameter in the web_snmp_notifyv3_add_post function.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-121
References: https://lafdrew.github.io/2025/04/20/web-snmp-notifyv3-add-post-host-ip/
CVE: CVE-2025-44893
Published: 2025-05-20
Description: FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the ruleNamekey parameter in the web_acl_mgmt_Rules_Apply_post function.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-121
References: https://github.com/xyqer1/Planet-web_acl_mgmt_Rules_Apply_post-ruleName-StackOverflow; https://lafdrew.github.io/2025/04/20/web-acl-mgmt-Rules-Apply-post-ruleName/; https://raw.githubusercontent.com/lafdrew/lafdrew.github.io/7e2c4ab[PII_REDACTED]4e61aa1384c2563ec008f49/2025/04/18/web-aaa-loginAuthlistEdit-get-authName-StackOverflow/index.html
CVE: CVE-2025-48056
Published: 2025-05-20
Description: Hubble is a fully distributed networking and security observability platform for cloud native workloads. Prior to version 1.17.2, a network attacker could inject malicious control characters into Hubble CLI terminal output, potentially leading to loss of integrity and manipulation of the output. This could be leveraged to conceal log entries, rewrite output, or even make the terminal temporarily unusable. Exploitation of this attack would require the victim to be monitoring Kafka traffic using Layer 7 Protocol Visibility at the time of the attack. The issue is patched in Hubble CLI v1.17.2. Hubble CLI users who are unable to upgrade can direct their Hubble flows to a log file and inspect the output within a text editor.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-74
References: https://github.com/cilium/cilium/pull/37401; https://github.com/cilium/hubble/security/advisories/GHSA-274q-79q9-52j7