Resolution for CVE-2024-44906

[storrdev]

Currently our anchore scanner warns us of a "moderate" level security vulnerability related to SQL injection via the "double dash" vulnerability, specifically in the pgdriver driver. (GHSA-h4h6-vccr-44h2)

Are there any plans to fix this vulnerability? I haven't seen any other issues raised here in github.

[Aoang]

Thank you for reporting this security concern and providing the GHSA-h4h6-vccr-44h2 reference. I appreciate you bringing this to my attention.

This SQL injection vulnerability in pgdriver is indeed linked to PostgreSQL's standard_conforming_strings configuration.

My assessment is as follows:

• standard_conforming_strings: This setting, when enabled, removes the need to escape backslashes. It has been the default behavior since PostgreSQL 9.1 (released in 2011, EOL in 2016). For details, see the PostgreSQL documentation and postgresqlco.nf for parameter history.
• Vulnerability Condition: The SQL injection risk primarily exists only if standard_conforming_strings is explicitly set to off.
• Industry Practice (e.g., pgx): I've observed that drivers like pgx incorporate logic to manage this parameter, and in some cases, even prevent its disabling.
• Impact Assessment: Considering standard_conforming_strings has been default-on for over a decade, and older versions that default to off are well past their end-of-life (e.g., PG 9.1 predates jsonb), it's highly improbable that a modern deployment using Bun would have this setting disabled. The parameter largely serves backward compatibility for very legacy environments. Therefore, I believe the affected user base for this specific vulnerability is extremely limited.

While the immediate impact appears low, a robust solution is certainly warranted. Determining the optimal fix, potentially drawing inspiration from pgx's approach (though I'd prefer a more elegant implementation), requires careful consideration.

They should be actively working on finding the best solution. Your patience is appreciated.

For reference:

https://www.postgresql.org/docs/current/runtime-config-compatible.html
https://postgresqlco.nf/doc/en/param/standard_conforming_strings/
https://github.com/jackc/pgx/blob/v5.7.5/pgconn/pgconn.go#L1813
https://github.com/jackc/pgx/blob/v5.7.5/conn.go#L1225

[thunderkatz]

Sorry, to clarify, is a solution actually being worked on? Is there any ETA? If not, I'm happy to try to write the fix myself and apply a similar approach from pgx.

[Aoang]

Sorry, to clarify, is a solution actually being worked on? Is there any ETA? If not, I'm happy to try to write the fix myself and apply a similar approach from pgx.

@thunderkatz Absolutely, we highly encourage external contributions!

For this particular issue, it would be best to first design a solution. This will help avoid potential roadblocks during the code review process. Code reviews tend to go much more smoothly when there's a mutually agreed-upon approach.

Please feel free to @ us if you need any assistance – we'd be happy to help.

On a related note, I suspect the release coming out next week will need this issue resolved, so time is of the essence. Good luck!

[thunderkatz]

I think per https://www.sonarsource.com/blog/double-dash-double-trouble-a-subtle-sql-injection-flaw/, the simplest solution is to follow the model set by pgx and pg-promise and simply wrap negative ints and floats in parentheses.

[Aoang]

I'm quite sure I misunderstood the original issue based on the limited information provided in GHSA-h4h6-vccr-44h2, where I only reviewed the first three linked references. This led me to mistakenly believe it was an escaping issue related to standard_conforming_strings=off.

In reality, it's a problem similar to what's described in GHSA-m7wr-2xf7-cm9p.

The exploitability of this particular vulnerability is much more stringent, and the underlying concept is quite intriguing – at least I've never personally encountered or written code that would lead to such a scenario.

Your contribution is very welcome!

---

A few of my own thoughts:

Since we are working with []byte, we could potentially add a check when appending numbers: if the preceding character is not a space, we could insert one.

[thunderkatz]

Hi, what needs to be done to get #1225 actually submitted? I don't seem to have the option to merge.

[thunderkatz]

#1225 is submitted, I think we're just waiting for a new release from the maintainers at this point.

[thunderkatz]

Hi, are there any blockers to getting a release out for this?

[j2gg0s]

Hi, are there any blockers to getting a release out for this?

If everything goes smoothly, I’ll release a new tag tomorrow.

[martoche]

Hi,

1. It looks like the title of this issue is not correct. It references "CVE-2024-34359", but should be "CVE-2024-44906".
2. This issue is not closed, but fix: put spaces before negative numbers following minus signs in format.go to resolve CVE-2024-34359 #1225 has been merged in master with commit 8067a8f and released in version 1.2.15. Can we close this issue?
3. I'm not sure what is the process to mark the CVE as resolved and the advisories (GHSA-h4h6-vccr-44h2 and https://pkg.go.dev/vuln/GO-2025-3765).

Thanks!

[Aoang]

Hi,

1. It looks like the title of this issue is not correct. It references "CVE-2024-34359", but should be "CVE-2024-44906".
2. This issue is not closed, but fix: put spaces before negative numbers following minus signs in format.go to resolve CVE-2024-34359 #1225 has been merged in master with commit 8067a8f and released in version 1.2.15. Can we close this issue?
3. I'm not sure what is the process to mark the CVE as resolved and the advisories (GHSA-h4h6-vccr-44h2 and https://pkg.go.dev/vuln/GO-2025-3765).

Thanks!

You are right, the title of this issue needs to be corrected. CC @j2gg0s

Regarding the process for marking the CVE as resolved and updating the advisories (GHSA-h4h6-vccr-44h2 and https://pkg.go.dev/vuln/GO-2025-3765), this typically requires maintainer or even owner privileges.

This should ideally be handled within the repository's security advisory section here: https://github.com/uptrace/bun/security/advisories

I don't have permission, therefore, i'd like to ask @j2gg0s and @vmihailenco to please look into this matter.

Thank you!

[martoche]

For those still using go-pg, I've opened a pull request with a similar fix:
go-pg/pg#2029