Apache Cloudberry version
datacenter=# select version();
version
PostgreSQL 14.4 (Apache Cloudberry 2.1.0-incubating build dev) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.0, 64-bit compiled on Jun 4 2026 10:54:54
(1 row)
What happened
PostgreSQL has disclosed CVE-2026-14669, a heap buffer overflow in to_char() related to overly long timezone abbreviations.
The vulnerability affects PostgreSQL versions prior to 14.24, 15.19, 16.15, 17.11, and 18.5.
Cloudberry 2.1 is based on PostgreSQL 14.x code, and the corresponding implementation in:
src/backend/utils/adt/formatting.c
appears to still contain the vulnerable timezone formatting path, for example:
strcpy(s, tmtcTzn(in));
without the bounds checking added by PostgreSQL upstream.
PostgreSQL upstream fix:
3d724bf4fde67a2931733a5143b7d6c12b23990c
Commit:
Guard against overlength time zone abbreviations in to_char().
What you think should happen instead
Please confirm whether Cloudberry 2.1 is affected by CVE-2026-14669 and, if so, backport the PostgreSQL upstream fix to the affected Cloudberry branches.
It would also be helpful to clarify:
Which Cloudberry versions are affected.
Whether the upstream fix has already been merged into any Cloudberry branch.
Whether the fix will be backported to Cloudberry 2.1.
Which Cloudberry release will contain the fix.
Recommended mitigation before a patched release is available.
How to reproduce
Compare Cloudberry's implementation in:
src/backend/utils/adt/formatting.c
with the PostgreSQL upstream fix for CVE-2026-14669.
In particular, check the handling of:
DCH_TZ
DCH_tz
The PostgreSQL fix adds length validation before copying timezone abbreviations into the to_char() output buffer.
No exploit PoC is included in this public issue.
Operating System
BigCloud Enterprise Linux For Euler 21.10 LTS
Anything else
CVE advisory:
https://www.postgresql.org/support/security/CVE-2026-14669/
PostgreSQL upstream fix:
postgres/postgres@3d724bf
PostgreSQL 14.24 release notes:
https://www.postgresql.org/docs/release/14.24/
Are you willing to submit PR?
Code of Conduct
Apache Cloudberry version
datacenter=# select version();
version
PostgreSQL 14.4 (Apache Cloudberry 2.1.0-incubating build dev) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.0, 64-bit compiled on Jun 4 2026 10:54:54
(1 row)
What happened
PostgreSQL has disclosed CVE-2026-14669, a heap buffer overflow in to_char() related to overly long timezone abbreviations.
The vulnerability affects PostgreSQL versions prior to 14.24, 15.19, 16.15, 17.11, and 18.5.
Cloudberry 2.1 is based on PostgreSQL 14.x code, and the corresponding implementation in:
src/backend/utils/adt/formatting.c
appears to still contain the vulnerable timezone formatting path, for example:
strcpy(s, tmtcTzn(in));
without the bounds checking added by PostgreSQL upstream.
PostgreSQL upstream fix:
3d724bf4fde67a2931733a5143b7d6c12b23990c
Commit:
Guard against overlength time zone abbreviations in to_char().
What you think should happen instead
Please confirm whether Cloudberry 2.1 is affected by CVE-2026-14669 and, if so, backport the PostgreSQL upstream fix to the affected Cloudberry branches.
It would also be helpful to clarify:
Which Cloudberry versions are affected.
Whether the upstream fix has already been merged into any Cloudberry branch.
Whether the fix will be backported to Cloudberry 2.1.
Which Cloudberry release will contain the fix.
Recommended mitigation before a patched release is available.
How to reproduce
Compare Cloudberry's implementation in:
src/backend/utils/adt/formatting.c
with the PostgreSQL upstream fix for CVE-2026-14669.
In particular, check the handling of:
DCH_TZ
DCH_tz
The PostgreSQL fix adds length validation before copying timezone abbreviations into the to_char() output buffer.
No exploit PoC is included in this public issue.
Operating System
BigCloud Enterprise Linux For Euler 21.10 LTS
Anything else
CVE advisory:
https://www.postgresql.org/support/security/CVE-2026-14669/
PostgreSQL upstream fix:
postgres/postgres@3d724bf
PostgreSQL 14.24 release notes:
https://www.postgresql.org/docs/release/14.24/
Are you willing to submit PR?
Code of Conduct