Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-r7wr-4w5q-55m6: Cilium vulnerable to information leakage via incorrect ReferenceGrant handling

### Impact When the [Gateway API](https://docs.cilium.io/en/v1.13/network/servicemesh/gateway-api/gateway-api/) is enabled in Cilium, the absence of a check on the namespace in which a [ReferenceGrant](https://gateway-api.sigs.k8s.io/api-types/referencegrant/) is created could result in Cilium gaining visibility of secrets (including certificates) and services across namespaces. An attacker on an affected cluster can configure Cilium to use cluster secrets or communicate with services that it should not have access to. Gateway API functionality is disabled by default. ### Patches This vulnerability is fixed in Cilium release 1.13.4. Cilium versions <1.13 are not affected. ### Workarounds There is no workaround to this issue. ### Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @meyskens for investigating and fixing the issue. ### For more information If you have any questions or comments about ...

ghsa
#vulnerability#git#kubernetes
GHSA-4xf2-7qfv-mgfx: ipandlanguageredirect extension vulnerable to SQL Injection

The ipandlanguageredirect extension before 5.1.2 for TYPO3 allows SQL Injection.

GHSA-f4m6-x2xj-jc7w: ke_search (aka Faceted Search) vulnerable to Cross-Site Scripting

The ke_search (aka Faceted Search) extension before 4.0.3, 4.1.x through 4.6.x before 4.6.6, and 5.x before 5.0.2 for TYPO3 allows XSS via indexed data.

GHSA-xc8m-28vv-4pjc: Kubelet vulnerable to bypass of seccomp profile enforcement

A security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. Pods that use localhost type for seccomp profile but specify an empty profile field, are affected by this issue. In this scenario, this vulnerability allows the pod to run in unconfined (seccomp disabled) mode. This bug affects Kubelet.

GHSA-gpv5-7x3g-ghjv: fast-xml-parser regex vulnerability patch could be improved from a safety perspective

### Summary This is a comment on https://github.com/NaturalIntelligence/fast-xml-parser/security/advisories/GHSA-6w63-h3fj-q4vw and the patches fixing it. ### Details The code which validates a name calls the validator: https://github.com/NaturalIntelligence/fast-xml-parser/blob/ecf6016f9b48aec1a921e673158be0773d07283e/src/xmlparser/DocTypeReader.js#L145-L153 This checks for the presence of an invalid character. Such an approach is always risky, as it is so easy to forget to include an invalid character in the list. A safer approach is to validate entity names against the XML specification: https://www.w3.org/TR/xml11/#sec-common-syn - an ENTITY name is a Name: ``` [4] NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] [4a] NameChar ::= N...

GHSA-qcwq-55hx-v3vh: snappy-java's unchecked chunk length leads to DoS

## Summary Due to use of an unchecked chunk length, an unrecoverable fatal error can occur. ## Impact Denial of Service ## Description The code in the function [hasNextChunk](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/SnappyInputStream.java#L388) in the file [SnappyInputStream.java](https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/SnappyInputStream.java) checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn’t possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk. ```java int readBytes = readNext(header, 0, 4); if (readBytes < 4) { return false; } int chunkSize = SnappyOutputStream.readInt(header, 0); if (chunkSize == SnappyCodec.MAGIC_HEADER_HEAD) { ......... } ...

GHSA-fjpj-2g6w-x25r: snappy-java's Integer Overflow vulnerability in compress leads to DoS

## Summary Due to unchecked multiplications, an integer overflow may occur, causing an unrecoverable fatal error. ## Impact Denial of Service ## Description The function [compress(char[] input)](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/Snappy.java#L169) in the file [Snappy.java](https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/Snappy.java) receives an array of characters and compresses it. It does so by multiplying the length by 2 and passing it to the [rawCompress](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/Snappy.java#L422) function. ```java public static byte[] compress(char[] input) throws IOException { return rawCompress(input, input.length * 2); // char uses 2 bytes } ``` Since the length is not tested, the multiplication by two can cause an integer overflow and become ne...

GHSA-pqr6-cmr2-h8hf: snappy-java's Integer Overflow vulnerability in shuffle leads to DoS

## Summary Due to unchecked multiplications, an integer overflow may occur, causing a fatal error. ## Impact Denial of Service ## Description The function [shuffle(int[] input)](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/BitShuffle.java#L107) in the file [BitShuffle.java](https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/BitShuffle.java) receives an array of integers and applies a bit shuffle on it. It does so by multiplying the length by 4 and passing it to the natively compiled shuffle function. ```java public static byte[] shuffle(int[] input) throws IOException { byte[] output = new byte[input.length * 4]; int numProcessed = impl.shuffle(input, 0, 4, input.length * 4, output, 0); assert(numProcessed == input.length * 4); return output; } ``` Since the length is not tested, the multiplication by four can cause an integer overflow and become ...

GHSA-p2qf-9vp6-3jjq: HuTool XML parsing module has blind XXE vulnerability

A vulnerability, which was classified as problematic, has been found in Dromara HuTool up to 5.8.19. Affected by this issue is the function readBySax of the file XmlUtil.java of the component XML Parsing Module. The manipulation leads to xml external entity reference.

GHSA-853p-5678-hv8f: ink! vulnerable to incorrect decoding of storage value when using `DelegateCall`

### Summary The return value when using delegate call mechanics, either through [`CallBuilder::delegate`](https://docs.rs/ink_env/4.2.0/ink_env/call/struct.CallBuilder.html#method.delegate) or [`ink_env::invoke_contract_delegate`](https://docs.rs/ink_env/4.2.0/ink_env/fn.invoke_contract_delegate.html), is being decoded incorrectly. ### Description Consider this minimal example: ```rust // First contract, this will be performing a delegate call to the `Callee`. #[ink(storage)] pub struct Caller { value: u128, } #[ink(message)] pub fn get_value(&self, callee_code_hash: Hash) -> u128 { let result = build_call::<DefaultEnvironment>() .delegate(callee_code_hash) .exec_input(ExecutionInput::new(Selector::new(ink::selector_bytes!( "get_value" )))) .returns::<u128>() .invoke(); result } // Different contract, using this code hash for the delegate call. #[ink(storage)] pub struct Callee { value: u128, } #[ink(message)] pu...