BUG #19602: Vuln46: citext split_part silently returns NULL for a zero field position instead of raising core sp

Started by PG Bug reporting formabout 13 hours ago1 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 19602
Logged by: Yuelin Wang
Email address: 1217816127@qq.com
PostgreSQL version: 19beta2
Operating system: Linux (Ubuntu 24.04, x86_64)
Description:

## Vuln46: citext split_part silently returns NULL for a zero field position
instead of raising core split_part's error

### Summary

citext.split_part(citext, citext, int) is implemented in SQL as an array
subscript expression (regexp_split_to_array(...))[$3] rather than by calling
pg_catalog.split_part. Postgres array subscripting silently returns NULL for
an out of range index such as 0, so citext's split_part diverges from core
split_part, which explicitly raises "field position must not be zero" for a
zero field argument.

CWE: CWE-1284. Severity: Low.

### PoC

```sql
CREATE EXTENSION citext;
SELECT split_part('abc~@~def~@~ghi'::citext, '~@~', 0) IS NULL AS is_null_0;
SELECT split_part('abc~@~def~@~ghi'::citext, '~@~', 0);
SELECT pg_catalog.split_part('abc~@~def~@~ghi', '~@~', 0);
```

### Result

Real captured output from the independent verification run:

```
CREATE EXTENSION
is_null_0
-----------
t
(1 row)

split_part
------------

(1 row)

ERROR: field position must not be zero
```

### Impact

An application that relies on split_part raising an error for a zero field
position to catch a programming or input validation bug will instead
silently receive NULL when operating on citext values, potentially masking
the underlying logic error rather than failing loudly.