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

Crash due to low Strict Transport Security Maximum Age

Open
  • Is something wrong?
#10,933 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@claucambra is already working on this.

Since Sep 28, 2026.

Assessment

This issue has not been assessed yet.

Description

bug os: :apple: macOS

This Nextcloud forum thread brought up a crash and helped to narrow down on the root cause which the client can handle better. The same kind of problem was already described in form of #8951.

Problem

The client turns on Qt's HSTS support with a saved on-disk store (OCC::AccessManager, since 3.17). Whenever the server sends a Strict-Transport-Security header, Qt caches a policy for that host that expires after max-age seconds. Before each request, Qt's QHstsCache::isKnownHost looks the host up. If the policy has expired, it removes the entry from its cache and then passes the entry it just removed to the store, reading memory that has already been freed. On macOS 13 and later, freed memory is zeroed, so this always crashes at address 0x8; on other systems the outcome depends on what is left in memory. The reporter's hoster sends max-age=5, so the cached policy expires five seconds after every response, and the client crashes on the first request after any five-second pause. That happens within the first minute of every launch. The bug has been in Qt since 2017 and is not fixed in any release, including dev.

Solution

The cleanest fix is a one-line change in Qt: move the addToObserved call in isKnownHost before the erase, so the store gets a copy while the entry is still valid. We'd ship it as a qtbase patch in our craft blueprints and also submit it upstream to Qt, which covers every place Qt calls that lookup. We shouldn't rely on the patch alone, because Linux distro builds use the system Qt. So the client should also clean up expired policies itself. In AccessManager::createRequest, just before handing the request to Qt, it collects the expired entries from strictTransportSecurityHosts() and passes them back through addStrictTransportSecurityHosts(). Qt removes them through a different code path without the bug, so the lookup that follows never meets an expired entry. That guard uses only public Qt API and worked in the standalone repro, but it doesn't cover the lookups Qt does internally (on redirects, for example), so it complements the Qt patch rather than replacing it. Both changes need a regression test: add a policy that expires almost immediately, wait, send a request, and check that the client doesn't crash and the entry is gone from both the cache and the store.

Dominant language
C++
Stars
3.9k
Forks
1k
Avg merge
1d 5h
Merged PRs (30d)
152

Getting set up

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 nextcloud/desktop

All issues in nextcloud/desktop

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.