GetFile answered on the webmail origin with the Content-Type stored in
the WOPI token, which for a mail attachment comes straight from the
launch request and for a Files node is a user-settable property. No
CSP, nosniff or disposition was added, since `/api/*` skips the proxy.
A user could mint a token for their own blob typed `text/html` and have
a victim open the GetFile URL, running script in the webmail origin.
GetFile now always sends `application/octet-stream` with
`Content-Disposition: attachment`, `nosniff` and a sandboxing CSP, and
refuses browser loads (any `Sec-Fetch-Dest` other than `empty`). The
editor fetches it server-to-server, so it is unaffected.
A MAPI property in a TNEF attachment declares how many values follow.
The parser looped that many times even when a value could not be read
and nothing was consumed, so a 31-byte winmail.dat claiming 0xFFFFFFFF
values froze the tab for about 13 seconds on every open, longer with
more such properties. The count is now clamped to what the block can
hold and the loop stops as soon as a value consumes no bytes.
The Authentication-Results parser matched `dmarc=` and `dkim=` anywhere
in all headers joined together. A sender who used `dmarc=pass@...` as
the envelope address got a green DMARC pass for a message that failed,
because the server echoes that address in the SPF clause before its
real `dmarc=fail`. A sender could also add their own
Authentication-Results header to an unsigned message and get a DKIM and
DMARC pass. Calendar invites from such a message were shown as trusted.
The parser now splits each header on `;` outside quoted strings and
comments and reads the method only at the start of a part. DKIM, DMARC
and iprev come from the topmost header, which the receiving server
wrote; lower headers can only escalate SPF to a failure.
The origin gate in the proxy only covered `/api/auth/*`. The JMAP
passthrough, `/api/settings`, `/api/wopi/launch`,
`/api/plugin-approval-status`, `/api/fetch-ical`, `/api/translate`,
`/api/caldav/discover`, `/api/calendar-agenda` and `/api/webdav` all act
with the session cookie and had no origin check. A page on a same-site
sibling origin receives SameSite=Lax cookies, so it could run arbitrary
JMAP as the signed-in user, including sharing mailboxes to a third
account.
The proxy now gates every `/api/` route except the WOPI file endpoints
the office editor calls server-to-server, and each of these handlers
checks again. The proxy also decides on the decoded path, so an escaped
spelling such as `/api/%61uth/session` no longer skips the gate.
An impersonation handoff sealed `<target>%<master>` and the master
password into the session cookie, and `PUT /api/auth/session` hands that
cookie's contents to the browser on every restore. Anyone who received
a handoff could read a credential that signs in as every mailbox and
into Stalwart administration, with no expiry and no audit trail.
The impersonate route now uses the master credential server-side, once,
to create an app password on the target mailbox that expires after
8 hours. Only that app password reaches the cookies. Signing out
revokes it through a sealed grant cookie, and PUT refuses any session
that still holds the configured master password, so cookies minted
before this change are dropped instead of returned.
The URL guard behind fetch-ical, OAuth discovery, branding and the
server-side JMAP fetches blocked only the single address 127.0.0.1 plus
the RFC 1918, link-local and ULA subnets. Any logged-in user could make
the server fetch 127.0.0.2, 100.64.0.0/10, 198.18.0.0/15, multicast,
reserved space or a NAT64/6to4/Teredo address that wraps an internal
IPv4 address.
The telemetry guard already rejected all of these (GHSA-m7j8), so its
range check moves to `lib/security/ip-ranges.ts` and both guards use it.
`guardedLookup` inherits the wider list, so the connect-time rebinding
check covers the new ranges too.
fetchUnifiedEmails and fetchCrossView set isUnifiedView:true synchronously
then await a network fetch with no check on completion that the view is
still current. If one resolved after the user had since selected a real
folder, it re-set isUnifiedView back to true while selectedMailbox stayed
on the folder - so a push-driven refreshCurrentMailbox (e.g. after
deleting a message) took the unified branch and blended in Inbox-tagged
messages instead of refreshing the folder.
Add a viewToken bumped by selectMailbox/selectKeyword/exitUnifiedView;
fetchUnifiedEmails/fetchCrossView capture it before fetching and discard
their result if it no longer matches on return. Also make selectMailbox/
selectKeyword defensively reset isUnifiedView/unifiedRole/crossView.
Upstream: bulwarkmail/webmail#1102
The re-sync effect depended on pushStatus.kind, so its own
setPushStatus({ kind: 'busy' }) re-fired the effect, whose cleanup
cancelled the in-flight enableWebPush - the push row then sat on
"Working…" forever and never updated the filter. Depend only on the
setting flip; read client/relay/status live from the recreated closure.
Flipping the setting only wrote to the store; the server-side JMAP push
filter stayed stale until the next app launch ran resyncWebPush. When push
is already enabled on the device, re-run enableWebPush on change so the
toggle takes effect without a restart.
Linus Rath
Linus Rath
Luis Felipe Marzagao
Aaron Guise