Merge upstream Prometheus v3.13.0 into invoca-2.55.1-base

[ColinDKelley]

Summary

Merge upstream Prometheus v3.13.0 (LTS, supported until 2027-07-31) into invoca-2.55.1-base, creating the 3.x integration anchor for Invoca's fork.

Stacked on invoca-2.55.1-base (#27 chain). No Invoca rate-func features in this branch — promql was taken from upstream 3.13 wholesale (merge kept stale Invoca xrate parser entries; fixed in second commit).

Lineage

invoca-2.53.1-base
└─ invoca-2.55.1-base (#27)
└─ invoca-3.13-base (#28, this PR) ← upstream v3.13.0
└─ (future) port-rate-funcs ← re-implement xrate/yrate + REPLACE_RATE_FUNCS

Why clean upstream PromQL?

Upstream 3.13 rewrote promql/functions.go (~1,600 lines changed vs 3.0). Invoca xrate/yrate from 2.55 will not cherry-pick — they must be re-ported against the new pickOrInterpolateLeft/pickOrInterpolateRight rate architecture. Starting from stock 3.13 PromQL avoids carrying 2.x fork debt forward.

Merge notes

• Conflicts in promql/engine.go, promql/functions.go, promql/promqltest/testdata/functions.test → resolved with upstream 3.13
• promql/parser/functions.go auto-merge kept Invoca xrate parser stubs → reset to upstream 3.13 in follow-up commit

Test plan

• go build ./...
• go test -count=1 ./promql/...
• Full go test ./... (optional; large)
• Staging spike checklist below before starting rate-func re-port

---

Pre-port spike checklist (ops / TSDB / integration)

Run these on this branch (or a throwaway deploy) before stacking invoca-3.13/port-rate-funcs. Goal: surface 3.x migration risk without touching Invoca PromQL yet.

Prerequisites

• 2.55.1 stack merged and staging has run on Invoca 2.55.1 for ≥ one retention window (TSDB bridge requirement per migration guide)
• Thanos pairing plan for 3.13 (likely v0.40.x+; 0.37.2 embeds 2.55-era prometheus only)

TSDB / data path

• Start 3.13 against TSDB written by 2.55.1 — confirm blocks load, no corruption errors
• Confirm downgrade path: 3.13 → 2.55.1 works; 3.13 → 2.53 does not (expected)
• WAL replay clean on restart after 2.55 → 3.13 cutover

Config / deployment breaking changes (migration guide)

• Scrape targets: Content-Type strictness — any targets need fallback_scrape_protocol?
• Alertmanager: api_version: v2 only (no v1)
• Remote write: http_config.enable_http2 default now false — verify remote_write still works if you rely on HTTP/2
• Feature flags removed from --enable-feature (now default or dedicated flags): expand-external-labels, no-default-scrape-port, agent, remote-write-receiver, auto-gomemlimit, auto-gomaxprocs
• scrape_classic_histograms → always_scrape_classic_histograms if used
• Log format changed (log/slog) — update any log parsers/alerts

PromQL behavior (upstream 3.x, no Invoca funcs yet)

• Spot-check dashboards using rate/increase on boundary-aligned subqueries — 3.x is (start, end]; subqueries like foo[1m:1m] may return fewer points (migration guide)
• Regex . now matches newlines — audit relabel/alert regexes if needed
• le/quantile label normalization — audit rules referencing integer le="1" (now le="1.0")

Thanos / ecosystem

• Build Invoca Thanos fork against 3.13 prometheus embed (new branch from v0.40.x?)
• Sidecar uploads blocks from 3.13 Prometheus
• Thanos Query evaluates standard PromQL against 3.13-embedded engine

Exit criteria for spike

• Staging shard runs 3.13 base for ≥ 24–48h without TSDB/scrape/alert regressions
• Known dashboard/recording-rule diffs documented (expected from 3.x semantics, not bugs)
• Only then: branch invoca-3.13/port-rate-funcs off this base

Related

• 2.55.1 feature stack: Fix xrate extended-range iteration and refresh rate-vs-xrate showcase (2.55) #21 → Add yrate/yincrease/ydelta (2.55) #22 → Align yrate/yincrease/ydelta with Prometheus 3.x (start, end] semantics #20 → Preserve upstream rate funcs as _rate when REPLACE_RATE_FUNCS is set #26
• LTS support table: https://prometheus.io/docs/introduction/release-cycle/

Wiz Scan Summary

⚠️ Many findings detected

Many findings were detected, but only a subset of the findings are displayed inline due to API constraints. To view all findings inline, please click here.

Scanner	Findings
Vulnerabilities	6  14  2
Sensitive Data	-
Secrets	-
IaC Misconfigurations	1  1
SAST Findings	15  27
Software Management Findings	-
Total	7  29  30

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentialsimport (
"github.com/aws/aws-sdk-go-v2/aws""github.com/aws/aws-sdk-go-v2/credentials"
)
creds:=credentials.NewStaticCredentialsProvider(
"AKIAIOSFODNN7EXAMPLE",
"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"",
)

// SECURE CODE - Using AWS credential providerimport (
"github.com/aws/aws-sdk-go-v2/config"
)
cfg, err:=config.LoadDefaultConfig(context.TODO())
iferr!=nil {
// Handle error
}
// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentialsimport (
"github.com/aws/aws-sdk-go-v2/aws""github.com/aws/aws-sdk-go-v2/credentials"
)
creds:=credentials.NewStaticCredentialsProvider(
"AKIAIOSFODNN7EXAMPLE",
"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"",
)

// SECURE CODE - Using AWS credential providerimport (
"github.com/aws/aws-sdk-go-v2/config"
)
cfg, err:=config.LoadDefaultConfig(context.TODO())
iferr!=nil {
// Handle error
}
// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

 SAST Finding

Overly Permissive File Permissions in Go (CWE-732)

More Details

The application is setting file permissions to overly permissive values, allowing unauthorized access to sensitive files. This vulnerability can lead to data breaches, unauthorized modifications, or execution of malicious code. Attackers who gain access to the system could exploit these excessive permissions to read, modify, or execute files they should not have access to.

To mitigate this risk, applications should assign the least permissive file permissions required for their intended functionality. Permissions should be carefully reviewed and restricted to only allow necessary operations for the application user or group.

Attribute	Value
Impact
Likelihood

Remediation

Setting overly permissive file permissions (greater than 0o640) exposes sensitive files to unauthorized users on the system. This violates the principle of least privilege and can lead to data breaches, unauthorized file modifications, or execution of malicious code by unintended users or groups. In multi-user environments, world-readable or world-writable files are especially dangerous.

To fix this issue, review all calls to os.Chmod, os.OpenFile, and os.WriteFile and restrict permissions to the minimum required. For most application files, 0o600 (owner read/write only) or 0o640 (owner read/write, group read) is sufficient. Avoid using permissions like 0o777, 0o755, or 0o666 unless there is a specific, documented requirement.

Code examples

// VULNERABLE CODE - World-readable and world-writable permissions expose the file to all usersfuncwriteConfig(filenamestring, data []byte) error {
returnos.WriteFile(filename, data, 0o777)
}
funcopenLog(filenamestring) (*os.File, error) {
returnos.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o666)
}

// SECURE CODE - Restricts access to owner only, preventing unauthorized reads or writesfuncwriteConfig(filenamestring, data []byte) error {
returnos.WriteFile(filename, data, 0o600)
}
funcopenLog(filenamestring) (*os.File, error) {
returnos.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o640)
}

Additional recommendations

• Use 0o600 for sensitive files (private keys, credentials, config files) to restrict access to the owner only.
• Use 0o640 when group read access is explicitly required by the application design.
• Never use world-writable permissions (0o777, 0o666, 0o646) on files containing sensitive data.
• Apply os.Chmod after file creation to enforce permissions even if the process umask is permissive.
• Set a restrictive umask (e.g., 0o027 or 0o077) at application startup as a defense-in-depth measure.
• This issue maps to CWE-732 and OWASP A01:2021 – Broken Access Control; follow your organization's security policy for file permission standards.

Rule ID: WS-I011-GO-00010

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

 SAST Finding

Regular Expression Denial of Service (ReDoS) in User Input Validation (CWE-185)

More Details

This rule detects instances where user-supplied input is matched against a regular expression without proper validation, potentially leading to a Regular Expression Denial of Service (ReDoS) vulnerability. ReDoS attacks exploit the fact that most Regular Expression implementations may take exponential time on certain input strings, causing excessive CPU consumption and effectively denying service to other users or system components.

This vulnerability presents a significant security risk as it can be exploited by an attacker to degrade or crash the application's performance, leading to a Denial of Service (DoS) condition. The consequences of a successful ReDoS attack can range from temporary unavailability of the application to complete system crashes, depending on the application's architecture and the resources available on the server.

To avoid this issue, it is crucial to validate and sanitize user input before processing it with regular expressions. Additionally, developers should carefully analyze the regular expressions used in their code to ensure they do not exhibit pathological behavior on specific input patterns.

Attribute	Value
Impact
Likelihood

Remediation

Regular expression denial of service (ReDoS) is a vulnerability that can occur when untrusted input is used in a regular expression pattern. An attacker can craft a malicious input string that causes the regular expression engine to go into an infinite loop, consuming excessive amounts of memory and CPU resources, leading to a denial of service condition. This vulnerability can be exploited to degrade or crash the application, potentially causing a service disruption.

To mitigate this vulnerability, it is essential to validate and sanitize user input before using it in regular expression operations. Additionally, it is recommended to use a regular expression engine that has protection against ReDoS attacks or to implement your own safeguards.

Code examples

// VULNERABLE CODE - The regular expression is applied directly to user input without validationconstuserInput=req.body.param;constregex=/^(a+)+$/;constresult=regex.test(userInput);

// SECURE CODE - User input is validated and sanitized before using in the regular expressionconstuserInput=req.body.param;constsanitizedInput=sanitizeInput(userInput);// Implement input sanitization functionconstregex=/^(a+)+$/;constresult=regex.test(sanitizedInput);

Additional recommendations

• Use a regular expression engine that has built-in protection against ReDoS attacks, such as the safe-regex library for Node.js.
• Implement input validation and sanitization to remove or escape potentially malicious characters from user input.
• Follow the principle of least privilege and use the most restrictive regular expression pattern possible.
• Consider using alternative string matching algorithms, such as substring matching or Boyer-Moore string search, for complex patterns or untrusted input.
• Adhere to the OWASP Cheat Sheet Series for input validation and sanitization best practices.
• Comply with relevant security standards, such as the OWASP Top 10 and CWE-185 (Incorrect Regular Expression).

Rule ID: WS-I002-JAVASCRIPT-00082

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

 Vulnerability Finding

The following vulnerabilities impact github.com/docker/docker versions <29.3.1: CVE-2026-33997, CVE-2026-34040, CVE-2026-41567, CVE-2026-41568, CVE-2026-42306.

These can be remediated by updating to version 29.3.1 or higher.

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

Suggested change

	github.com/docker/docker v28.5.2+incompatible// indirect
	github.com/docker/docker v29.3.1// indirect

 Vulnerability Finding

The following vulnerabilities impact github.com/prometheus/prometheus versions <0.311.3: CVE-2026-40179, CVE-2026-42151, CVE-2026-42154, CVE-2026-44903.

These can be remediated by updating to version 0.311.3 or higher.

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

Suggested change

	github.com/prometheus/prometheus v0.308.1
	github.com/prometheus/prometheus v0.311.3

 Vulnerability Finding

The following vulnerabilities impact github.com/prometheus/prometheus versions <0.311.3: CVE-2026-40179, CVE-2026-42151, CVE-2026-42154, CVE-2026-44903.

These can be remediated by updating to version 0.311.3 or higher.

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

Suggested change

	github.com/prometheus/prometheus v0.307.4-0.20251119130332-1174b0ce4f1f// indirect
	github.com/prometheus/prometheus v0.311.3// indirect

 Vulnerability Finding

More Details

Vulnerabilities [github.com/docker/docker:28.5.2+incompatible]

Name	Severity	Source	Fixed version	CVSS score	CVSS exploitability score	Has public exploit	Has CISA KEV exploit
CVE-2026-33997		https://github.com/advisories/GHSA-pxq6-2prw-chj9	-	8.1	2.8	false	false
CVE-2026-41567		https://github.com/advisories/GHSA-x86f-5xw2-fm2r	-	7.2	0.8	false	false
CVE-2026-41568		https://github.com/advisories/GHSA-vp62-88p7-qqf5	-	6.1	0.8	false	false
CVE-2026-42306		https://github.com/advisories/GHSA-rg2x-37c3-w2rh	-	7.2	0.8	false	false

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentialsimport (
"github.com/aws/aws-sdk-go-v2/aws""github.com/aws/aws-sdk-go-v2/credentials"
)
creds:=credentials.NewStaticCredentialsProvider(
"AKIAIOSFODNN7EXAMPLE",
"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"",
)

// SECURE CODE - Using AWS credential providerimport (
"github.com/aws/aws-sdk-go-v2/config"
)
cfg, err:=config.LoadDefaultConfig(context.TODO())
iferr!=nil {
// Handle error
}
// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentialsimport (
"github.com/aws/aws-sdk-go-v2/aws""github.com/aws/aws-sdk-go-v2/credentials"
)
creds:=credentials.NewStaticCredentialsProvider(
"AKIAIOSFODNN7EXAMPLE",
"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"",
)

// SECURE CODE - Using AWS credential providerimport (
"github.com/aws/aws-sdk-go-v2/config"
)
cfg, err:=config.LoadDefaultConfig(context.TODO())
iferr!=nil {
// Handle error
}
// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate