## Summary
Bumps **brace-expansion -> 5.0.8** in the three app lockfiles whose copy
sits on the 5.x line, clearing **GHSA-mh99-v99m-4gvg** (high, vulnerable
`<= 5.0.7`) on those manifests:
- `examples/hello-world` (`^5.0.2`)
- `examples/postcard` (`^5.0.5`)
- `internal/self-hosting` (`^5.0.5`)
All three are caret ranges, so a recursive `yarn up -R brace-expansion`
lifts them with **no resolution and no `package.json` change**.
## Why the fixtures are not included
This advisory declares a single vulnerable range, `<= 5.0.7`, which
spans **every** major line - so the `brace-expansion@2.1.2` copies in
`seed-dependencies` and `common-layer-dependencies` are flagged as well.
But **2.1.2 is the last 2.x release** (1.x likewise ends at 1.1.16), and
the only patched version is **5.0.8**. Those consumers declare `^2.0.1`
/ `^2.0.2`, which caps below 3.0.0, so there is no in-range fix:
clearing them would mean forcing a cross-major jump from 2.x to 5.x via
a resolution, which is a behavior risk rather than a mechanical lift.
Same situation for the root alert
([1765](https://github.com/twentyhq/twenty/security/dependabot/1765)),
where `nx` pins `brace-expansion` 5.0.6 exact.
## Verification
- brace-expansion resolves to **5.0.8** in all three lockfiles.
- `yarn install --immutable` passes in each.
- 5.0.8 published 2026-07-23, clears the 3-day npm age gate.
## Summary
Bumps **postcss -> 8.5.22** in the 13 twenty-apps lockfiles that carry
it transitively, clearing **GHSA-r28c-9q8g-f849** (high) on those
manifests: path traversal in previous source map auto-loading
(`sourceMappingURL`) leading to arbitrary `.map` file disclosure,
vulnerable `<= 8.5.17`.
Apps covered: document-generator, hello-world, postcard, self-hosting,
twenty-partners, call-recorder, people-data-labs, twenty-discord,
twenty-exa, twenty-fireflies, twenty-last-contact, twenty-linear,
twenty-slack.
Every app reaches postcss through a caret range (`^8.5.15`), so a
recursive `yarn up -R postcss` lifts it in each project with **no
resolution and no `package.json` change** - the diff is 13 `yarn.lock`
files and nothing else. Yarn resolves to **8.5.22**, the latest in range
(above the 8.5.18 fix floor).
## Not included
The **root lockfile** carries the same advisory but its postcss copies
are held by exact pins - `next` (8.4.31 in every stable release,
including 16.2.11) and `@mintlify/common` (8.5.14, unchanged in its
latest) - so no `yarn up` reaches it. That one needs a scoped resolution
and is handled separately.
## Verification
- postcss resolves to **8.5.22** in all 13 lockfiles; nothing at or
below 8.5.17 remains.
- `yarn install --immutable` passes in each of the 13 projects.
- 8.5.22 published 2026-07-22, clears the 3-day npm age gate.
## Summary
Bumps **tar -> 7.5.21** in the 13 twenty-apps lockfiles that carry it
transitively, clearing **GHSA-r292-9mhp-454m** (medium) on those
manifests: uncontrolled recursion in `mapHas`/`filesFilter` allows an
uncatchable stack-overflow DoS via a crafted long-path tar with member
selection, vulnerable `<= 7.5.20`.
Apps covered: document-generator, hello-world, postcard, self-hosting,
twenty-partners, call-recorder, people-data-labs, twenty-discord,
twenty-exa, twenty-fireflies, twenty-last-contact, twenty-linear,
twenty-slack.
Every app reaches tar through a caret range (`^7.5.4`), so a recursive
`yarn up -R tar` lifts it in each project with **no resolution and no
`package.json` change** - the diff is 13 `yarn.lock` files and nothing
else.
## Not included
- **Root lockfile**: same advisory, shipped separately in #23330.
- **`application-package/constants/seed-dependencies`**: the 14th
manifest with this advisory. Its `yarn.lock` is checksum-coupled to
`DEFAULT_YARN_LOCK_CHECKSUM`, so it moves in its own PR with the
constant regenerated alongside.
## Verification
- tar resolves to **7.5.21** in all 13 lockfiles; nothing below remains.
- `yarn install --immutable` passes in each of the 13 projects.
- 7.5.21 published 2026-07-21, clears the 3-day npm age gate.
## Summary
Sweeps the **twenty-apps lockfiles** for this week's advisory wave:
recursive `yarn up` for **axios, tar, brace-expansion, body-parser** in
each of the 12 apps with open Dependabot alerts (hello-world, postcard,
self-hosting, twenty-partners, call-recorder, people-data-labs,
twenty-discord, twenty-exa, twenty-fireflies, twenty-last-contact,
twenty-linear, twenty-slack).
All moves fit the declared ranges (apps carry these transitively via
`twenty-sdk`, whose `axios ^1.16.0` and deep tar/brace chains are
carets), so the diff is **lockfile-only** across all 12 manifests - no
resolutions, no `package.json` changes. axios -> 1.18.x, tar -> 7.5.20
(critical GHSA-23hp-3jrh-7fpw chain), brace-expansion -> 1.1.16 / 2.1.2
/ 5.0.7, body-parser -> 1.20.6 / 2.3.0.
The second commit narrows scope to apps only: the twenty-server fixture
projects (seed-dependencies, common-layer-dependencies) move to a
dedicated PR because seed-dependencies' yarn.lock is checksum-coupled to
`DEFAULT_YARN_LOCK_CHECKSUM` in
`get-default-application-package-fields.util.ts`; it also drops
accidentally committed `.yarn/install-state.gz` artifacts.
## Deliberately not covered
- **sharp**: every path is minor-locked at `^0.34.5` (including
twenty-sdk latest) - separate PR bumping twenty-sdk's range.
- **react-router / react-router-dom**: no fixed release on the 6.x line
(fix is the v7 major); tracked separately.
## Verification
- Vulnerable-version scan across all 12 lockfiles: no axios <1.18, tar
<7.5.19, brace-expansion below 1.1.16/2.1.2/5.0.7, or body-parser below
1.20.6/2.3.0 remains.
- `yarn install --immutable` passes in each app.
- All fix versions clear the 3-day npm age gate.
## What
Upgrades the internal `self-hosting` app to the latest Twenty CLI
tooling, bringing it in line with the other actively-maintained apps in
the monorepo.
- `twenty-sdk`: `2.19.0-alpha.1` → `2.23.0-alpha.2` (dependency +
devDependency)
- `twenty-client-sdk`: `2.19.0-alpha.1` → `2.23.0-alpha.2` (dependency +
devDependency)
- `engines.twenty`: `>=2.19.0` → `>=2.23.0`
- Regenerated `yarn.lock` to match.
The `twenty` CLI ships inside `twenty-sdk`, so this pulls the app onto
the same CLI version every other recently-updated app (call-recorder,
people-data-labs, twenty-partners, real-estate, last-contact, postcard)
already uses.
## Verification
- `yarn typecheck` passes
- `yarn lint` passes (0 warnings, 0 errors)
- `yarn test:unit` passes (3/3)
Integration tests (`yarn test`) require a running Twenty server and were
not run in this environment.
## Notes
Scope is limited to the CLI/SDK tooling. Framework deps (React 18) were
left untouched since they are not tied to the CLI version and vary
across apps.
---
_Generated by [Claude
Code](https://claude.ai/code/session_01HUPkxerLhethaP9Lw6qDyd)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/23279?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Summary
- Bumps `twenty-sdk` / `twenty-client-sdk` to the exact `2.19.0-alpha.1`
prerelease for the apps under `packages/twenty-apps` that actually
target a mutated standard identifier, and refreshes their lockfiles.
- Declares `"engines": { "twenty": ">=2.19.0" }` in those apps so
pre-2.19 servers refuse to install or upgrade to the rebuilt packages.
Only apps that reference a standard object's **system-field** universal
identifier, define a **relation into** a standard object, or call the
field-UID derivation helper need 2.19 (the identifiers those touch
changed from hardcoded UUIDs to deterministic hashes). Apps that only
define their own custom objects, or add plain scalar fields to a
standard object via its stable object-level id, were left on their prior
SDK pins. Currently bumped: `postcard`, `self-hosting`,
`twenty-partners`, `call-recorder`, `people-data-labs`,
`twenty-last-contact`.
## Context
Follow-up to #22565 (deterministic system field universal identifiers)
and #22599 (SDK prerelease bump).
Packages built with SDK ≤ 2.18 carry legacy system field identifiers and
are rejected by servers running `main`. Rebuilding with the 2.19 SDK
fixes that — but a rebuilt package must not be *upgraded into* by a 2.18
server, since 2.18 has no deterministic-identifier validation and would
diff the changed system field identifiers as a destructive delete +
create (the 2.19 backfill has not run there yet).
The `engines.twenty` constraint closes that gap: `doInstallApplication`
validates it via `validateServerCompatibility` before any mutation, and
this check has shipped since ~2.10, so every 2.18 server enforces it.
Resulting matrix:
- 2.18 fresh install of a rebuilt app: works, converges as a no-op once
the 2.19 backfill runs
- 2.18 upgrade of an existing install: rejected with
`SERVER_VERSION_INCOMPATIBLE` before any mutation
- 2.19 (post-backfill) install/upgrade: syncs cleanly
## Expected CI failures
**The `CI Twenty Apps` integration-test jobs are expected to fail on
this PR** (e.g. `people-data-labs`, `twenty-partners`). This is a
server-version mismatch, not an app bug — lint, typecheck and unit tests
all pass:
- The integration step spawns a real Twenty server from Docker Hub
`twentycrm/twenty-app-dev:latest` and runs `twenty dev` to sync each
app's metadata into it.
- `latest` currently resolves to **v2.18.5** — no `2.19` image is
published to Docker Hub yet.
- These apps now reference 2.19's **deterministic system-field universal
identifiers** (e.g. `company.createdBy`, `opportunity.createdAt`). A
2.18 server still carries the legacy identifiers, so the sync rejects
every 2.19-derived reference with `INVALID_VIEW_DATA` /
`FIELD_METADATA_NOT_FOUND` ("Field metadata not found").
- The failure surfaces as low-level field errors rather than a clean
`SERVER_VERSION_INCOMPATIBLE` because the `engines.twenty` gate
(`validateServerCompatibility`) only runs on the `app:install` / publish
paths — **not** on the `twenty dev` dev-sync path the integration tests
use.
These jobs will go green automatically once `twenty-app-dev:2.19` is
published to Docker Hub (or once CI pins the spawn action's
`twenty-version` to a 2.19 tag).
## Intentionally not included
- App `version` fields are untouched; they'll be bumped at publish time.
## Test plan
- [x] Refresh each bumped app's `yarn.lock` (`2.19.0-alpha.1` is now on
npm)
- [ ] Rebuild one app manifest and verify default field identifiers
match `getFieldUniversalIdentifier`
- [ ] Verify a 2.18 server rejects an upgrade to a rebuilt package with
`SERVER_VERSION_INCOMPATIBLE`
- [ ] Re-run `CI Twenty Apps` integration jobs once a
`twenty-app-dev:2.19` image is available
Made with [Cursor](https://cursor.com)
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22601?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-light.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## fix(security): bump tar to 7.5.16 across lockfiles (PAX file
smuggling)
Resolves [#1472 1474 1476 1479 1481 1483 1485 1487 1489 1491 1493 1496
1498 1505](https://github.com/twentyhq/twenty/security/dependabot/1472
1474 1476 1479 1481 1483 1485 1487 1489 1491 1493 1496 1498 1505).
### What
`tar` (`node-tar`) `<= 7.5.15` applies a PAX size override to
intermediary GNU long-name/long-link headers, causing a tar-parser
interpretation differential (file smuggling). Patched in `7.5.16`.
### Why these alerts
The advisory is scanned across many independent Yarn projects, so it
surfaced as one alert per lockfile: the root `yarn.lock` plus 13
`packages/twenty-apps/**` lockfiles (each pulls `tar` transitively).
### How
- Refreshed `tar` to `7.5.16` in the root and all 13 app lockfiles —
they hold `tar` via `^7.5.x` ranges that already permit it, so this is
an in-range lockfile refresh (no override) via `yarn up -R tar`.
- The root additionally had `tar@7.5.15` exact-pinned by
`@mintlify/previewing`, which has **no upstream fix** (latest `4.0.1163`
still pins `7.5.15`). Added a scoped resolution
`@mintlify/previewing/tar -> ^7.5.16`, **extending the existing scoped
tar resolutions** already used for `@electron/rebuild` and
`@electron/node-gyp`.
### Not included
`seed-dependencies/yarn.lock` (alert #1500) is intentionally excluded:
that lockfile and its checksum constants are already modified by the
open form-data PR, so its `tar` bump will follow separately to avoid a
conflict.
### Verification
- No `tar <= 7.5.15` remains across the root or any app lockfile.
- `yarn install --immutable` passes.
## What
Bumps **all 14 `twenty-apps`** (internal, examples, community) to the
freshly published SDK **2.13.0**, and upgrades `vitest` 3 → 4 so `vite`
resolves to 8 (rolldown).
- `twenty-sdk` / `twenty-client-sdk`: `2.10.1` → `2.13.0` (each app's
original spec format preserved — plain, `^`, and `npm:…@`).
- `vitest`: `^3.x` → `^4.0.0` in the 13 apps that use it
(`call-recording` has no vitest).
## Why
Each app's `yarn.lock` had open Dependabot esbuild alerts — high
`GHSA-gv7w-rqvm-qjhr` and low `GHSA-g7r4-m6w7-qqqr`, both fixed in
esbuild `0.28.1`.
The SDK bump alone does **not** clear them: the advisories fire on *any*
esbuild `< 0.28.1`, and each app pulled a vulnerable `esbuild@0.27.7`
transitively via **vite** (through the `vitest` devDependency),
independent of the SDK. Bumping `vitest` to 4 resolves `vite@8`
(rolldown), which drops the esbuild dependency entirely.
`twenty-partners` additionally needed a recursive esbuild re-resolution
(its `tsx` dep had `esbuild@~0.28.0` pinned at the still-vulnerable
`0.28.0`).
After this change, **all 14 lockfiles resolve esbuild `0.28.1` only** —
zero copies `< 0.28.1`.
## Test
- All 14 lockfiles verified free of esbuild `< 0.28.1`.
- vitest 4 + vite 8 confirmed working: `people-data-labs` runs **334
tests across 83 files, all passing**.
- `twenty-for-twenty`'s suite fails only because its global setup
requires a live Twenty server (`/healthz`) — environmental, would fail
identically under vitest 3.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21553?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
Resolves the **vitest Critical** Dependabot alerts
(`GHSA-5xrq-8626-4rwp`, vitest `< 3.2.6`) — #1422–#1433.
Each `packages/twenty-apps/*` project is an **independent yarn project**
with its own `package.json` + `yarn.lock` (not part of the root
workspace). 12 of them declared `vitest: ^3.1.1` and locked an older
3.2.x. This bumps the range to `^3.2.6` and refreshes each lockfile to
**3.2.6** (latest 3.x, published 2026-06-01).
Projects updated: `community/github-connector`,
`examples/{hello-world,postcard}`,
`internal/{exa,people-data-labs,self-hosting,twenty-discord,twenty-fireflies,twenty-for-twenty,twenty-linear,twenty-partners,twenty-slack}`.
- Dev-scope only (test runner); no runtime impact.
- The **root workspace already uses vitest 4.x** (≥ the fix) and is
intentionally untouched.
- Verified: no `vitest < 3.2.6` remains in any `twenty-apps` lockfile.
## What
The standalone apps under `packages/twenty-apps/*` each ship **their own
`yarn.lock`** (they're not part of the root workspace), and those
lockfiles still pulled vulnerable transitive versions of `axios`,
`undici`, `tmp`, `qs`, `ws`, `brace-expansion`, `uuid` (via `twenty-sdk`
/ `twenty-client-sdk`). This was ~130 of the open Dependabot alerts —
none of them reachable from the root-lockfile PRs.
Ran `yarn up -R` per app to re-resolve the vulnerable transitives within
their existing ranges, across all 13 flagged apps:
- **`axios` → 1.17.0** — clears the entire proxy-auth-leak / ReDoS /
config-merge MITM advisory set (the 56 axios alerts)
- **`qs`, `brace-expansion`, `uuid`** → patched
- **`undici`, `ws`** → patched on the in-range majors (older majors that
parents pin exactly remain, same situation as the root lockfile)
## Scope
- **Lockfile-only**, 13 apps. No `package.json` changes.
- Test **fixtures** (`packages/twenty-apps/fixtures/*`) intentionally
left untouched — Dependabot didn't flag them and they back snapshot
tests.
- Fixes self host application
- add new telemetry information
- add serverId to identify a server instance
- remove .twenty from git tracking
- tree-shake "twenty-sdk" usage in built logic functions and front
components
- fix "twenty-sdk" version usage
- fix twenty-zapier cli
---------
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Abdullah.
