<?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>Sun, 04 Oct 2026 11:41:27 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-73841</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-73841</link>
      <description>&lt;p&gt;OpenChoreo is a complete, open-source developer platform for Kubernetes. Prior to 1.1.6 and 1.2.3, internal/openchoreo-api/api/handlers/exec.go and internal/openchoreo-api/api/handlers/wirelogs.go authorize component:exec and wirelogs:view using the caller-supplied project query parameter instead of comp.Spec.Owner.ProjectName, allowing a user with a project-scoped grant to execute commands in and read wirelogs from components owned by other projects in the same namespace. This vulnerability is fixed in 1.1.6 and 1.2.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;OpenChoreo is a complete, open-source developer platform for Kubernetes. Prior to 1.1.6 and 1.2.3, internal/openchoreo-api/api/handlers/exec.go and internal/openchoreo-api/api/handlers/wirelogs.go authorize component:exec and wirelogs:view using the caller-supplied project query parameter instead of comp.Spec.Owner.ProjectName, allowing a user with a project-scoped grant to execute commands in and read wirelogs from components owned by other projects in the same namespace. This vulnerability is fixed in 1.1.6 and 1.2.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-73841</guid>
    </item>
    <item>
      <title>GHSA-52gf-6rpq-fgmx — OpenChoreo: Cross-project command execution and wirelog view access via OpenChoreo openchoreo-api exec and wirelogs end…</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-52gf-6rpq-fgmx</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/openchoreo/openchoreo&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The OpenChoreo API server (`openchoreo-api`) authorized requests to its exec and wirelogs endpoints against the project supplied by the caller in the request, rather than against the project that actually owns the target component. The target component was resolved by name only, and the authorization engine decided purely from the caller-supplied resource hierarchy — the component&amp;#39;s real owning project was never checked. As a result, an authenticated user who holds a project-scoped exec or log-viewing grant on any single project could run commands in, and read the wirelogs of, components owned by other projects in the same namespace.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An authenticated tenant holding a project-scoped `component:exec` grant on just one project can execute arbitrary commands — including an interactive shell — inside the running pods of components owned by any other project in the same namespace. This exposes those workloads&amp;#39; environment variables and mounted Secrets (such as database credentials, API keys, and tokens), allows tampering with the workload, and enables further pivoting using the workload&amp;#39;s own network position and credentials. The same flaw in the wirelogs endpoint lets a project-scoped `wirelogs:view` grant read any component&amp;#39;s wirelogs in the namespace.&lt;/p&gt;
&lt;p&gt;The blast radius is every component in the namespace, reachable from a single legitimate project grant. The boundary crossed is project-within-namespace: the request still pins the namespace, so the issu…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/openchoreo/openchoreo&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The OpenChoreo API server (`openchoreo-api`) authorized requests to its exec and wirelogs endpoints against the project supplied by the caller in the request, rather than against the project that actually owns the target component. The target component was resolved by name only, and the authorization engine decided purely from the caller-supplied resource hierarchy — the component&amp;#39;s real owning project was never checked. As a result, an authenticated user who holds a project-scoped exec or log-viewing grant on any single project could run commands in, and read the wirelogs of, components owned by other projects in the same namespace.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An authenticated tenant holding a project-scoped `component:exec` grant on just one project can execute arbitrary commands — including an interactive shell — inside the running pods of components owned by any other project in the same namespace. This exposes those workloads&amp;#39; environment variables and mounted Secrets (such as database credentials, API keys, and tokens), allows tampering with the workload, and enables further pivoting using the workload&amp;#39;s own network position and credentials. The same flaw in the wirelogs endpoint lets a project-scoped `wirelogs:view` grant read any component&amp;#39;s wirelogs in the namespace.&lt;/p&gt;
&lt;p&gt;The blast radius is every component in the namespace, reachable from a single legitimate project grant. The boundary crossed is project-within-namespace: the request still pins the namespace, so the issu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-52gf-6rpq-fgmx</guid>
    </item>
  </channel>
</rss>
