Latest News

Red Hat Security Advisory 2024-4517-03 - An update for firefox is now available for Red Hat Enterprise Linux 8.

Red Hat Security Advisory 2024-4508-03 - An update for firefox is now available for Red Hat Enterprise Linux 7 Extended Lifecycle Support.

Red Hat Security Advisory 2024-4502-03 - An update for skopeo is now available for Red Hat Enterprise Linux 9. Issues addressed include a memory leak vulnerability.

Red Hat Security Advisory 2024-4501-03 - An update for firefox is now available for Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions.

Red Hat Security Advisory 2024-4500-03 - An update for firefox is now available for Red Hat Enterprise Linux 9.

Red Hat Security Advisory 2024-4326-03 - An update is now available for Red Hat build of Quarkus. Issues addressed include a denial of service vulnerability.

Red Hat Security Advisory 2024-2106-03 - An update is now available for Red Hat build of Quarkus.

The cybercrime group demands ransoms of varying degrees, from thousands to even millions of dollars — in some cases, 2 bitcoin per encrypted customer.

### Impact Editors that use `MediaEmbedElement` and pass custom `urlParsers` to the `useMediaState` hook may be vulnerable to XSS if a custom parser allows `javascript:`, `data:` or `vbscript:` URLs to be embedded. Editors that do not use `urlParsers` and instead consume the `url` property directly may also be vulnerable if the URL is not sanitised. The default parsers `parseTwitterUrl` and `parseVideoUrl` are not affected. Examples of vulnerable code: ```tsx const { embed } = useMediaState({ urlParsers: [ // Custom parser that does not use an allowlist or validate the URL protocol (url) => ({ url }), ], }); return ( <iframe src={embed!.url} // ... /> ); ``` ```tsx const { url } = useMediaState(); return ( <iframe // url property used directly from useMediaState() with no sanitisation src={url} // ... /> ); ``` ```tsx const { url } = element; return ( <iframe // url property used directly from element with no sanitisation src={...

RISC Zero zkVM was designed from its inception to provide three main guarantees: 1. *Computational integrity*: that a given software program executed correctly. 2. *Succinctness*: that the proof of execution does not grow in relation to the program being executed. 3. *Zero Knowledge*: that details of the program execution are not visible within the proof of program execution. Ulrich Habock and Al Kindi have released [new research] that indicates that several STARK implementations -including our RISC Zero zkVM- do not meet the requirements to assert the specific property of zero knowledge provably. While a vast majority of real-world applications that leverage RISC Zero zkVM or similar systems depend primarily on computational integrity and succinctness, a subset of applications critically depend on the privacy guarantees provided by zero-knowledge; and for those use cases, users are cautioned to understand the research and make informed decisions based on the risks outlined in using...