<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 03:00:08 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-46146 — Prometheus Exporter Toolkit vulnerable to basic authentication bypass</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2022-46146</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; prometheus exporter-toolkit&lt;/p&gt;
&lt;p&gt;Prometheus Exporter Toolkit is a utility package to build exporters. Prior to versions 0.7.2 and 0.8.2, if someone has access to a Prometheus web.yml file and users&amp;#39; bcrypted passwords, they can bypass security by poisoning the built-in authentication cache. Versions 0.7.2 and 0.8.2 contain a fix for the issue. There is no workaround, but attacker must have access to the hashed password to use this functionality.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; prometheus exporter-toolkit&lt;/p&gt;
&lt;p&gt;Prometheus Exporter Toolkit is a utility package to build exporters. Prior to versions 0.7.2 and 0.8.2, if someone has access to a Prometheus web.yml file and users&amp;#39; bcrypted passwords, they can bypass security by poisoning the built-in authentication cache. Versions 0.7.2 and 0.8.2 contain a fix for the issue. There is no workaround, but attacker must have access to the hashed password to use this functionality.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2022-46146</guid>
    </item>
    <item>
      <title>GHSA-cgrx-mc8f-2prm — runc container escape and denial of service due to arbitrary write gadgets and procfs write redirects</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-cgrx-mc8f-2prm</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/opencontainers/runc, Go: github.com/opencontainers/selinux&lt;/p&gt;
&lt;p&gt;### Impact ###&lt;/p&gt;
&lt;p&gt;This attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy `tmpfs` file and thus not apply the correct LSM labels to the container process. The mitigation runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files.&lt;/p&gt;
&lt;p&gt;Rather than using a fake `tmpfs` file for `/proc/self/attr/&amp;lt;label&amp;gt;`, an attacker could instead (through various means) make `/proc/self/attr/&amp;lt;label&amp;gt;` reference a real `procfs` file, but one that would still be a no-op (such as `/proc/self/sched`). This would have the same effect but would clear the &amp;#34;is a procfs file&amp;#34; check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as &amp;#34;future work&amp;#34; at conferences), and runc is working on a far more comprehensive mitigation of this attack, but this security issue was disclosed before runc could complete this work.&lt;/p&gt;
&lt;p&gt;In all known versions of runc, an attacker can trick runc into misdirecting writes to `/proc` to other procfs files through the use of a racing container with shared mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with `docker buildx build` as that also permits triggering parallel execution of containers with custom shared mounts configured). This r…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/opencontainers/runc, Go: github.com/opencontainers/selinux&lt;/p&gt;
&lt;p&gt;### Impact ###&lt;/p&gt;
&lt;p&gt;This attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy `tmpfs` file and thus not apply the correct LSM labels to the container process. The mitigation runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files.&lt;/p&gt;
&lt;p&gt;Rather than using a fake `tmpfs` file for `/proc/self/attr/&amp;lt;label&amp;gt;`, an attacker could instead (through various means) make `/proc/self/attr/&amp;lt;label&amp;gt;` reference a real `procfs` file, but one that would still be a no-op (such as `/proc/self/sched`). This would have the same effect but would clear the &amp;#34;is a procfs file&amp;#34; check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as &amp;#34;future work&amp;#34; at conferences), and runc is working on a far more comprehensive mitigation of this attack, but this security issue was disclosed before runc could complete this work.&lt;/p&gt;
&lt;p&gt;In all known versions of runc, an attacker can trick runc into misdirecting writes to `/proc` to other procfs files through the use of a racing container with shared mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with `docker buildx build` as that also permits triggering parallel execution of containers with custom shared mounts configured). This r…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-cgrx-mc8f-2prm</guid>
    </item>
  </channel>
</rss>
