Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Request for GHSA/CVE for the vCard VALUE type confusion fixed in v4.0.6 (PR #1375)

Open
  • Is something wrong?
#1,438 5 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
security

Research direction

Read the vCard VALUE handling in vcardparser.c, especially the paths noted around line 735, and compare it with the compatibility validation in icalparser.c:1008 and the helper in vcardderivedproperty.c.in. The issue says the parser-side mismatch remains open despite PR #1375; investigate how VALUE overrides are validated. Done means incompatible property/value kinds are rejected or reset, including the noted TEXTLIST path, with the supplied 315-combination matrix used to check behavior.

Written by the indexing model from the issue text.

Description

Hello maintainers,
I'd like to request that a repository security advisory (GHSA) be filed
retroactively for the vCard VALUE type confusion that was fixed in PR #1375
("libicalvcard: make the typed value getters and setters type-safe", merged
2026-09-09, shipped in v4.0.6) and credit for the original report.
Summary of the vulnerability (CWE-843, Access of Resource Using Incompatible Type):
The vCard parser (vcardparser.c) lets an explicit VALUE parameter replace the
expected value kind of a property without any compatibility check:

  • vcardparser.c: state->value_kind is replaced by whatever VALUE= names;
  • the value is then constructed for that kind and attached with
    vcardproperty_set_value() — no property/value validation;
  • vcardproperty_value_kind_is_valid() exists (vcardderivedproperty.c.in) but
    has zero call sites — the iCalendar parser (icalparser.c:1008) does run the
    equivalent check and resets the kind, the vCard parser does not;
  • consumers that dispatch on the property kind (e.g. Cyrus IMAP's
    ContactCard/parse and CardDAV vCard 4->3 transform) then call typed getters
    (vcardproperty_get_n/get_adr/get_bday) on the mismatched union member.
    Impact: attacker-controlled union reinterpretation — for BDAY;VALUE=URI the URI
    pointer is returned as a vcardtimetype (exact heap-address disclosure through
    JMAP JSON); for N;VALUE=URI the URI bytes become a vcardstructuredtype
    (attacker-chosen pointer dereference and, in a transform harness, a controlled
    free/zero-write). A 21-property x 15-value-kind matrix (315 combinations) showed
    288 accepted by the parser/restriction path and 68 SIGSEGV outcomes.
    Fix status: PR #1375 (credited: "This issue was reported by
    interpolwantme [email protected]") hardened the typed getters on the
    4.0 branch and shipped in v4.0.6. Thank you for that.
    Two follow-ups I'd like to ask about:
  1. Could a repository security advisory (GHSA) with a CVE be filed for this
    issue retroactively, crediting the discovery? The getter hardening alone
    warranted the API-breaking treatment it received, and downstream consumers
    (Cyrus IMAP ContactCard/parse, CardDAV) pass untrusted vCard data straight
    into these getters.
  2. The parser-side root cause — VALUE parameter override without a
    compatibility check (vcardparser.c), with the compatibility helper still
    having zero call sites — remains open on master. The iCalendar parser
    already implements the equivalent validation (icalparser.c:1008), so the
    pattern exists in-tree; a version-aware port to vcardparser.c would close
    the class. The typed-getter hardening does not cover consumers that read
    vcardproperty_get_value() directly, nor the VALUE=TEXTLIST construction
    path (vcardparser.c:735) which also builds a pointer-bearing value for
    arbitrary properties.
    I have a full 315-combination test matrix, a minimal patch for the parser-side
    check, and ASAN/Valgrind traces available if useful.
    Thanks,
    interpolwantme
Dominant language
C
Stars
366
Forks
127
Avg merge
16h 25m
Merged PRs (30d)
34

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from libical/libical

All issues in libical/libical

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.