Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact When run as a server, OPA exposes an HTTP Data API for reading and writing documents. Requesting a virtual document through the Data API entails policy evaluation, where a Rego query containing a single data document reference is constructed from the requested path. This query is then used for policy evaluation. A HTTP request path can be crafted in a way that injects Rego code into the constructed query. The evaluation result cannot be made to return any other data than what is generated by the requested path, but this path can be misdirected, and the injected Rego code can be crafted to make the query succeed or fail; opening up for oracle attacks or, given the right circumstances, erroneous policy decision results. Furthermore, the injected code can be crafted to be computationally expensive, resulting in a Denial Of Service (DoS) attack. Users are only impacted if all of the following apply: OPA is deployed as a standalone server (rather than being used as a Go library)…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A SMB force-authentication vulnerability exists in all versions of OPA for Windows prior to v0.68.0. The vulnerability exists because of improper input validation, allowing a user to pass an arbitrary SMB share instead of a Rego file as an argument to OPA CLI or to one of the OPA Go library’s functions.
Recommended action: Upgrade to 0.68.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/open-policy-agent/opa >= 0.40.0, < 0.43.1
Fixed in
0.43.1· Vendor fix available
Issue
Impact The Rego compiler provides a (deprecated) WithUnsafeBuiltins function, which allows users to provide a set of built-in functions that should be deemed unsafe — and as such rejected — by the compiler if encountered in the policy compilation stage. A bypass of this protection has been found, where the use of the with keyword to mock such a built-in function (a feature introduced in OPA v0.40.0), isn’t taken into account by WithUnsafeBuiltins. The same method is exposed via rego.UnsafeBuiltins in the github.com/open-policy-agent/opa/rego package. When provided e.g. the http.send built-in function to WithUnsafeBuiltins, the following policy would still compile, and call the http.send function with the arguments provided to the isobject function when evaluated: Both built-in functions and user provided (i.e. custom) functions are mockable using this construct. In addition to http.send, the opa.runtime built-in function is commonly considered unsafe in integrations where policy…
Recommended action: Upgrade to 0.43.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue in the AST parser (ast/compile.go) of Open Policy Agent v0.10.2 allows attackers to cause a Denial of Service (DoS) via a crafted input.
Recommended action: Upgrade to 0.42.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue in the component ast/parser.go of Open Policy Agent v0.39.0 causes the application to incorrectly interpret every expression, causing a Denial of Service (DoS) via triggering out-of-range memory access.
Recommended action: Upgrade to 0.40.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/open-policy-agent/opa >= 0.33.1, < 0.37.2
Fixed in
0.37.2· Vendor fix available
Issue
Impact Under certain conditions, pretty-printing an AST that contains synthetic nodes could change the logic of some statements by reordering array literals. Example of policies impacted are those that parse and compare web paths, see the example below. All of these three conditions have to be met to create an adverse effect: 1. An AST of Rego had to be created programmatically such that it ends up containing terms without a location (such as wildcard variables). 2. The AST had to be pretty-printed using the github.com/open-policy-agent/opa/format package. 3. The result of the pretty-printing had to be parsed and evaluated again via an OPA instance using the bundles, or the Golang packages. If any of these three conditions are not met, you are not affected. Notably, all three would be true if using optimized bundles, i.e. bundles created with opa build -O=1 or higher. In that case, the optimizer would fulfil condition (1.), the result of that would be pretty-printed when writing the…
Recommended action: Upgrade to 0.37.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.