## The defect `EntitySnapshot::build()` answers for a config entity with its label and nothing else: ```php if (!$entity instanceof FieldableEntityInterface) { return ['_label' => (string) ($entity->label() ?? '')]; } ``` Every config entity takes that branch. So an audit row for a config change carries `state: {"_label": "..."}` and, when the label did not move, no `delta` at all — which is every config change that is not a rename. The entry-detail page then renders that row's before/after panel as **"No fields changed. Every captured value is identical on both sides."** ## Why it matters The bridge deliberately keeps the security-relevant config types trackable. `EntityAuditSettingsForm::getTrackableEntityTypes()` says so in its own words: > Security-relevant types like `filter_format` (XSS filter, allowed HTML tags), `editor` (CKEditor plugins) and `action` (configurable system actions, some of which can execute PHP) are NOT in this list: admin edits to those are exactly the kind of event a compliance audit needs. `user_role` is not on the list either, so a permission grant is in scope as well. None of those edits can be read off the row they produce. `README.md` offers config entities as a first-class audited type ("nodes, taxonomy terms, users, custom config entities, …"), describes before/after field snapshots and a side-by-side diff, and nowhere says a config entity records only its label. The module already holds the whole config array at that moment: `EntitySnapshot::getStoredDigest()` reads `toArray()` on the same entity to decide whether the save was a no-op, and throws it away. ## Proof Throwaway kernel probe against unpatched 1.x, granting `administer audit trail` to a role with `user_role` tracked: ``` action=update resource=entity:user_role/probe_role permanent={} transient={"uid":0,...,"_v":1,"state":{"_label":"Probe role"},"key_order":["_label"]} ``` The permission that was granted appears nowhere. `audit_trail_user_auth`'s `role_changed` does not cover it: that event is about assigning a role to an account, not about what the role may do. ## The fix Snapshot a config entity from `toArray()`, flattened to the shape the diff renderer already reads: - a scalar stays a scalar; - a list of scalars stays a list, so `user_role.permissions` renders through `buildListDiff()` as an item-level added/removed view; - a nested mapping recurses under dotted keys, so `filters.filter_html.settings.allowed_html` is one diffable row. `selected_fields` then names top-level config keys, as it names field names for a content entity. **And it refuses credential-bearing types by construction of the rule, not by accident.** `key` is a hard dependency of this module and `key.provider.config` stores `key_value` — the raw bytes — inside the config entity. One of those keys is this module's own HMAC signing secret. Snapshotting `toArray()` without a refusal would write the secret that signs the chain into the chain, into the archive, and onto a page any holder of `view audit trail reports` can read. Such a type keeps the label-only snapshot: record that the key changed, never the bytes, which is what `CREDENTIAL_FIELD_TYPES` already does for `user.pass`. Found by the whole-module audit of 2026-09-15. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary, as part of a file-by-file audit of the module, and to write the fix and its tests on the merge request where one is attached. Every test named here was run locally and confirmed to fail against the unpatched code and to pass with the change. The merge requests are open as drafts, pending my review.)