Skip to content

chore(deps): update module github.com/open-policy-agent/opa to v1 [security] #928

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps): update module github.com/open-policy-agent/opa to v1 [security] #928

wants to merge 1 commit into from

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented May 6, 2025 •
edited
Loading

This PR contains the following updates:

Package Change Age Confidence
github.com/open-policy-agent/opa v0.70.0 -> v1.4.0 age confidence

GitHub Vulnerability Alerts

CVE-2025-46569

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)
  • The OPA server is exposed outside of the local host in an untrusted environment.
  • The configured authorization policy does not do exact matching of the input.path attribute when deciding if the request should be allowed.

or, if all of the following apply:

  • OPA is deployed as a standalone server.
  • The service connecting to OPA allows 3rd parties to insert unsanitised text into the path of the HTTP request to OPA’s Data API.

Note: With no Authorization Policy configured for restricting API access (the default configuration), the RESTful Data API provides access for managing Rego policies; and the RESTful Query API facilitates advanced queries. Full access to these APIs provides both simpler, and broader access than what the security issue describes here can facilitate. As such, OPA servers exposed to a network are not considered affected by the attack described here if they are knowingly not restricting access through an Authorization Policy.

Patches

Fixed in OPA v1.4.0.

Workarounds

Don’t publicly expose OPA’s RESTful APIs

Unless necessary for production reasons, network access to OPA’s RESTful APIs should be limited to localhost and/or trusted networks.
Since OPA v1.0, unless otherwise configured, the server listener defaults to localhost.

Enable Authentication to Only Allow Access to Trusted Clients

A configured authentication scheme is a requirement when OPA is exposed in an untrusted environment. While requiring authentication alone doesn’t mitigate this attack, it effectively reduces the scope from untrusted clients to trusted clients.

Perform Path Validation Using OPA’s Authorization Policy Functionality

OPA can be configured to use an Authorization Policy to validate all incoming requests.
By authoring the Authorization Policy to only accept paths corresponding to expected Rego package references, this attack can be fully mitigated.

The HTTP path in a Data API request is of the format /v1/data/{path:.+} (/v0/data/{path:.+}, for the v0 Data API), where data/{path:.+} directly corresponds to a reference to a virtual document, and a prefix of {path:.+} corresponds to a Rego package declaration.
E.g. the HTTP path v1/data/do/re/mi corresponds to the data reference data.do.re.mi, where do.re is the package and mi is the rule in the following Rego module:

package do.re

mi if {
	...
}

Unless otherwise configured, OPA will use the rule at data.system.authz.allow as Authorization Policy. Authorization is enabled by starting OPA with the --authorization=basic flag, and the Authorization policy must be made available to the OPA runtime either through a bundle (via the --bundle flag or through discovery) or as an individual module via the command-line.

A trivial Authorization Policy example:

package system.authz

allowed_paths := [
	["v1", "data", "policy1", "allow"],
	["v1", "data", "policy2", "allow"],
	...
]

allow if {
	input.path in allowed_paths
}

Note: configuring an Authorization Policy in OPA isn't the only way to protect against malicious request paths. Path validation and sanitisation can also be performed by connecting clients and 3rd party intermediaries, such as API gateways, reverse proxies, etc.

Release Notes

open-policy-agent/opa (github.com/open-policy-agent/opa)

v1.4.0

Compare Source

This release contains a security fix addressing CVE-2025-46569.
It also includes a mix of new features, bugfixes, and dependency updates.

Security Fix: CVE-2025-46569 - OPA server Data API HTTP path injection of Rego (GHSA-6m8w-jc87-6cr7)

A vulnerability in the OPA server's Data API allows an attacker to craft the HTTP path in a way that injects Rego code into the query that is evaluated.
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)
  • The OPA server is exposed outside of the local host in an untrusted environment.
  • The configured authorization policy does not do exact matching of the input.path attribute when deciding if the request should be allowed.

or, if all of the following apply:

  • OPA is deployed as a standalone server.
  • The service connecting to OPA allows 3rd parties to insert unsanitised text into the path of the HTTP request to OPA’s Data API.

Note: With no Authorization Policy configured for restricting API access (the default configuration), the RESTful Data API provides access for managing Rego policies; and the RESTful Query API facilitates advanced queries.
Full access to these APIs provides both simpler, and broader access than what the security issue describes here can facilitate.
As such, OPA servers exposed to a network are not considered affected by the attack described here if they are knowingly not restricting access through an Authorization Policy.

This issue affects all versions of OPA prior to 1.4.0.

See the Security Advisory for more details.

Reported by @​GamrayW, @​HyouKash, @​AdrienIT, authored by @​johanfylling

Runtime, Tooling, SDK
Topdown and Rego
Docs, Website, Ecosystem
Miscellaneous
  • Dependency updates; notably:
    • build(deps): bump github.com/hypermodeinc/badger from v4.6.0 to v4.7.0
    • build(deps): bump github.com/spf13/viper from 1.18.2 to 1.20.1
    • build(deps): bump golang.org/x/net from 0.37.0 to 0.38.0
    • build(deps): bump google.golang.org/grpc from 1.71.0 to 1.71.1
    • build(deps): bump oras.land/oras-go/v2 from 2.3.1 to 2.5.0

v1.3.0

Compare Source

This release contains a mix of features, bugfixes, and dependency updates.

New Buffer Option for Decision Logs (#​5724)

A new, optional, buffering mechanism has been added to decision logging.
The default buffer is designed around making precise memory footprint guarantees, which can produce lock contention at high loads, negatively impacting query performance.
The new event-based buffer is designed to reduce lock contention and improve performance at high loads, but sacrifices the memory footprint guarantees of the default buffer.

The new event-based buffer is enabled by setting the decision_logs.reporting.buffer_type configuration option to event.

For more details, see the decision log plugin README.

Reported by @​mjungsbluth, authored by @​sspaink

OpenTelemetry: HTTP Support and Expanded Batch Span Configuration (#​7412)

Distributed tracing through OpenTelemetry has been extended to support HTTP collectors (enabled by setting the distributed_tracing.type configuration option to http).
Additionally, configuration has been expanded with fine-grained batch span processor options.

Authored and reported by @​sqyang94

Runtime, Tooling, SDK
Docs, Website, Ecosystem
Miscellaneous
  • Enable unused-receiver linter (revive) (#​7448) authored by @​anderseknert
  • Dependency updates; notably:
    • build(deps): bump github.com/containerd/containerd from 1.7.26 to 1.7.27
    • build(deps): bump github.com/dgraph-io/badger/v4 from 4.5.1 to 4.6.0
    • build(deps): bump github.com/opencontainers/image-spec from 1.1.0 to 1.1.1
    • build(deps): bump github.com/prometheus/client_golang 1.21.0 to 1.21.1
    • build(deps): bump golang.org/x/net from 0.35.0 to 0.37.0
    • build(deps): bump golang.org/x/time from 0.10.0 to 0.11.0
    • build(deps): bump google.golang.org/grpc from 1.70.0 to 1.71.0
    • build(deps): bump go.opentelemetry.io deps to 1.35.0/0.60.0

v1.2.0

Compare Source

This release contains a mix of features, performance improvements, and bugfixes.

Parameterized Rego Tests (#​2176)

Rego tests now support parameterization, allowing a single test rule to include multiple, hierarchical, named test cases.
This feature is useful for data-driven testing, where a single test rule can be used for multiple test cases with different inputs and expected outputs.

package example_test

test_concat[note] if {
	some note, tc in {
		"empty + empty": {
			"a": [],
			"b": [],
			"exp": [],
		},
		"empty + filled": {
			"a": [],
			"b": [1, 2],
			"exp": [1, 2],
		},
		"filled + filled": {
			"a": [1, 2],
			"b": [3, 4],
			"exp": [1, 2, 3], # Faulty expectation, this test case will fail
		},
	}

	act := array.concat(tc.a, tc.b)
	act == tc.exp
}
$ opa test example_test.rego
example_test.rego:
data.example_test.test_concat: FAIL (263.375µs)
  empty + empty: PASS
  empty + filled: PASS
  filled + filled: FAIL
--------------------------------------------------------------------------------
FAIL: 1/1

See the documentation for more information.

Authored by @​johanfylling, reported by @​anderseknert

Performance Improvements
Topdown and Rego
Runtime, Tooling, SDK
Docs, Website, Ecosystem
Miscellaneous
  • build+test: Add make test-short task (#​7364) (authored by @​anderseknert)
  • build: Add gocritic linter (#​7377) authored by @​anderseknert
  • build: Add nilness linter from govet (#​7335) authored by @​anderseknert
  • build: Add perfsprint linter (#​7334) authored by @​anderseknert
  • ci: Tagging release binaries with build version (#​7395, #​7397, #​7400) authored by @​johanfylling
  • test: fix race in TestIntraQueryCache_ClientError and TestInterQueryCache_ClientError (#​7280) authored by @​Juneezee
  • misc: Use Go 1.22+ int ranges (#​7328) authored by @​anderseknert
  • Dependency updates; notably:
    • build: bump go from 1.23.5 to 1.24.0
    • build(deps): bump github.com/agnivade/levenshtein from 1.2.0 to 1.2.1
    • build(deps): bump github.com/containerd/containerd from 1.7.25 to 1.7.26
    • build(deps): bump github.com/google/go-cmp from 0.6.0 to 0.7.0
    • build(deps): bump github.com/prometheus/client_golang
    • build(deps): bump github.com/spf13/cobra from 1.8.1 to 1.9.1
    • build(deps): bump github.com/spf13/pflag from 1.0.5 to 1.0.6
    • build(deps): bump golang.org/x/net from 0.34.0 to 0.35.0
    • build(deps): bump golang.org/x/time from 0.9.0 to 0.10.0
    • build(deps): bump ossf/scorecard-action from 2.4.0 to 2.4.1
    • Bump golangci-lint from v1.60.1 to 1.64.5

v1.1.0

Compare Source

This release contains a mix of features, performance improvements, and bugfixes.

Performance Improvements
Topdown and Rego
Runtime, Tooling, SDK
Docs, Website, Ecosystem
Miscellaneous
  • ci(nightly): Remove vendor w/o modproxy check (#​7292) authored by @​srenatus
  • Dependency updates; notably:
    • build(go): bump to 1.23.5 (7279) authored by @​srenatus
    • build(deps): upgrade github.com/dgraph-io/badger to v4 (4.5.1) (#​7239) authored by @​Juneezee
    • build(deps): bump github.com/containerd/containerd from 1.7.24 to 1.7.25
    • build(deps): bump github.com/tchap/go-patricia/v2 from 2.3.1 to 2.3.2
    • build(deps): bump golang.org/x/net from 0.33.0 to 0.34.0
    • build(deps): bump golang.org/x/time from 0.8.0 to 0.9.0
    • build(deps): bump google.golang.org/grpc from 1.69.2 to 1.70.0
    • build(deps): bump go.opentelemetry.io deps to 1.34.0/0.59.0

v1.0.1

Compare Source

This is a bug fix release addressing the following issues:

  • build(go): bump to 1.23.5 (authored by @​srenatus).
    Addressing CVE-2024-45341 and CVE-2024-45336 vulnerabilities in the Go runtime.
  • bundle: Add info about the correct rego version to parse modules on the store, co-authored by @​ashutosh-narkar and @​johanfylling in #​7278.
    Fixing an issue where the rego-version for individual modules was lost during bundle deactivation (bundle lifecycle) if this version diverged from the active runtime rego-version.
    This could cause reloading of v0 bundles to fail when OPA was not running with the --v0-compatible flag.

v1.0.0

Compare Source

NOTES:

  • The minimum version of Go required to build the OPA module is 1.22

We are excited to announce OPA 1.0, a milestone release consolidating an improved developer experience for the future of Policy as Code. The release makes new functionality designed to simplify policy writing and improve the language's consistency the default.

Changes to Rego in OPA 1.0

Below we highlight some key changes to the defaults in OPA 1.0:

  • Using if for all rule definitions and contains for multi-value rules is now mandatory, not just when using the rego.v1 import.
  • Other new keywords (every, in) are available without any imports.
  • Some requirements that were previously only run in "strict mode" (opa check --strict) are now the default. Duplicate imports and imports which shadow each other are no longer allowed.
  • OPA 1.0 comes with a range of backwards compatibility features to aid your migrations, please see the v0 compatibility guide
    if you must continue to support v0 Rego.

Read more about the OPA 1.0 announcement here on our blog.

Following are other changes that are included in OPA 1.0.

Improvements to memory allocations

PRs #​7172, #​7190, #​7193, #​7165, #​7168, #​7191 & #​7222 together improve the memory performance of OPA. Key strategies
include reusing pointers and optimizing array and object operations, minimizing intermediate object creation, and using sync.Pool
to manage memory-heavy operations. These changes cumulatively greatly reduced the number of allocations and improved
evaluation speed by 10-20%. Additional benchmarks highlighted significant memory and speed improvements in custom
function evaluation.

Authored by @​anderseknert.

Wrap http.RoundTripper for SDK users

PR #​7180 adds an EvalHTTPRoundTrip EvalOption and query-level WithHTTPRoundTrip option.
Both use a new function type which converts an http.Transport configured by topdown to an http.RoundTripper.
This supports use cases requiring the customization of the http.send built in behavior.

Authored by @​evankanderson.

Improvements to scientific notation parsing in units.parse

PR #​7147 extends the behaviour of extractNumAndUnit to support
scientific notation values. This means values such as 1e3KB can now be handled by this function.

Authored by @​berdanA.

Support customized buckets bundle_loading_duration_ns metric

PR #​7156 extends OPA’s Prometheus configuration to allow the
setting of user defined buckets for metrics. This aids when debugging the loading of slow bundles.

Authored by @​jwu730-1.

Test suite performance improvements

PR #​7126 updates tests to improve performance. Topdown and storage/disk/
tests now run around 50% and 75% faster respectively.

Authored by @​philipaconrad.

OPA 1.0 Preparation
Topdown and Rego
Runtime, Tooling, SDK
Docs, Website, Ecosystem
Dependency Updates
  • (build) golangci-lint: v1.59.1 -> v1.60.1 by @​srenatus in #​7175
  • github.com/containerd/containerd: v1.7.23 -> v1.7.24
  • github.com/fsnotify/fsnotify: v1.7.0 -> v1.8.0
  • golang.org/x/net: v0.30.0 -> v0.33.0
  • golang.org/x/time: v0.7.0 -> v0.8.0
  • google.golang.org/grpc: v1.67.1 -> v1.69.2
  • go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp: v0.53.0 -> v0.58.0
  • go.opentelemetry.io/otel: v1.28.0 -> v1.33.0
  • go.opentelemetry.io/otel/exporters/otlp/otlptrace: v1.28.0 -> v1.33.0
  • go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc: v1.28.0 -> v1.33.0
  • go.opentelemetry.io/otel/sdk: v1.28.0 -> v1.33.0
  • go.opentelemetry.io/otel/trace: v1.28.0 -> v1.33.0

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
chore(deps): update module github.com/open-policy-agent/opa to v1 [se…
f396525 
…curity]

| datasource | package                          | from    | to     |
| ---------- | -------------------------------- | ------- | ------ |
| go         | github.com/open-policy-agent/opa | v0.70.0 | v1.4.0 |
@renovate
Copy link
Contributor Author

renovate bot commented May 6, 2025 •
edited
Loading

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: go.sum
Command failed: go get -t ./...
go: module github.com/open-policy-agent/[email protected] requires go >= 1.23.8; switching to go1.24.6
go: downloading go1.24.6 (linux/amd64)
go: download go1.24.6: golang.org/[email protected]: verifying module: checksum database disabled by GOSUMDB=off

@renovate renovate bot requested a review from a team May 6, 2025 01:09
@renovate renovate bot added the dependencies Pull requests that update a dependency file label May 6, 2025
@renovate renovate bot changed the title chore(deps): update module github.com/open-policy-agent/opa to v1 [security] chore(deps): update module github.com/open-policy-agent/opa to v1 [security] - autoclosed May 20, 2025
@renovate renovate bot closed this May 20, 2025
@renovate renovate bot deleted the renovate/go-github.com-open-policy-agent-opa-vulnerability branch May 20, 2025 01:01
@renovate renovate bot changed the title chore(deps): update module github.com/open-policy-agent/opa to v1 [security] - autoclosed chore(deps): update module github.com/open-policy-agent/opa to v1 [security] May 20, 2025
@renovate renovate bot reopened this May 20, 2025
@renovate renovate bot force-pushed the renovate/go-github.com-open-policy-agent-opa-vulnerability branch from 85a4ae6 to f396525 Compare May 20, 2025 05:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant