Vulnerabilities

HCL BigFix RunBookAI is affected by a Unvalidated Command Input / Potential Command Smuggling vulnerability. A flaw in a component's input handling was identified that could permit unauthorized command execution.

HCL BigFix RunBookAI is affected by a Continued availability of Less-Secure “Input Text” Vulnerability . A component contains a security weakness in its input handling implementation, increasing the risk of misconfiguration and operational errors.

A flaw was found in Keylime. An attacker with root access on an enrolled monitored machine, where the Keylime agent runs, can exploit a vulnerability in the Keylime verifier. The verifier uses a hardcoded challenge nonce for Trusted Platform Module (TPM) quote attestation instead of a cryptographically random value. This allows the attacker to stockpile valid TPM quotes and replay them to evade detection after compromising the system. This issue affects only the push model deployment.

HCL DFXAnalytics is affected by an Insecure Security Header Configuration vulnerability where the application utilizes the outdated X-XSS-Protection header, which could allow an attacker to exploit browser-specific rendering flaws or bypass security controls that should instead be managed by a robust Content Security Policy (CSP).

HCL DFXAnalytics is affected by an Improper Error Handling vulnerability where the application exposes detailed stack traces in responses, which could allow an attacker to gain insights into the application's internal structure, code logic, and environment configurations.

HCL DFXAnalytics is affected by an Insufficient Transport Layer Protection vulnerability where data is transmitted over the network without encryption, which could allow an attacker to compromise the confidentiality, integrity, and authentication of sensitive information.

HCL DFXAnalytics is affected by a Using Components with Known Vulnerabilities flaw where the application utilizes unpatched libraries or sub-components, which could allow an attacker to identify and exploit publicly known security vulnerabilities to gain unauthorized access or compromise the application.

HCL DFXAnalytics is affected by an Insecure Security Header configuration vulnerability where the Content-Security-Policy does not define strict directives for object-src and base-uri, which could allow an attacker to exploit injection vectors such as Cross-Site Scripting (XSS)

FolderUploadsFileManager in Apache Wicket does not validate or sanitize the uploadFieldId parameter or the clientFileName<br /> before constructing file paths, allowing an unauthenticated attacker to<br /> write arbitrary files outside the intended upload directory or read <br /> files from arbitrary locations on the server.<br /> <br /> This issue affects Apache Wicket: from 8.0.0 through 8.17.0, from 9.0.0 through 9.22.0, from 10.0.0 through 10.8.0.<br /> <br /> Users are recommended to upgrade to version 10.9.0, which fixes the issue.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Wicket.<br /> <br /> This issue affects Apache Wicket: from 8.0.0 through 8.17.0, from 9.0.0 through 9.22.0, from 10.0.0 through 10.8.0.<br /> <br /> Users are recommended to upgrade to version 10.9.0, which fixes the issue.

A TCP client can perform a TLS handshake and present the server name extension with a server name that is accepted by a server wildcard name, e.g. if the server is configured with a certificate accepting *.example.com, any XYZ.example.com where xyz is a valid name can be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix zero size inode with non-zero size after log replay<br /> <br /> When logging that an inode exists, as part of logging a new name or<br /> logging new dir entries for a directory, we always set the generation of<br /> the logged inode item to 0. This is to signal during log replay (in<br /> overwrite_item()), that we should not set the i_size since we only logged<br /> that an inode exists, so the i_size of the inode in the subvolume tree<br /> must be preserved (as when we log new names or that an inode exists, we<br /> don&amp;#39;t log extents).<br /> <br /> This works fine except when we have already logged an inode in full mode<br /> or it&amp;#39;s the first time we are logging an inode created in a past<br /> transaction, that inode has a new i_size of 0 and then we log a new name<br /> for the inode (due to a new hardlink or a rename), in which case we log<br /> an i_size of 0 for the inode and a generation of 0, which causes the log<br /> replay code to not update the inode&amp;#39;s i_size to 0 (in overwrite_item()).<br /> <br /> An example scenario:<br /> <br /> mkdir /mnt/dir<br /> xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo<br /> <br /> sync<br /> <br /> xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo<br /> <br /> ln /mnt/dir/foo /mnt/dir/bar<br /> <br /> xfs_io -c "fsync" /mnt/dir<br /> <br /> <br /> <br /> After log replay the file remains with a size of 64K. This is because when<br /> we first log the inode, when we fsync file foo, we log its current i_size<br /> of 0, and then when we create a hard link we log again the inode in exists<br /> mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we<br /> add to the log tree, so during log replay overwrite_item() sees that the<br /> generation is 0 and i_size is 0 so we skip updating the inode&amp;#39;s i_size<br /> from 64K to 0.<br /> <br /> Fix this by making sure at fill_inode_item() we always log the real<br /> generation of the inode if it was logged in the current transaction with<br /> the i_size we logged before. Also if an inode created in a previous<br /> transaction is logged in exists mode only, make sure we log the i_size<br /> stored in the inode item located from the commit root, so that if we log<br /> multiple times that the inode exists we get the correct i_size.<br /> <br /> A test case for fstests will follow soon.