Skip to content

Archive

Cybersecurity

535 articles
Cybersecurity 19 Sep 2026 6 min read

WebAuthn Signature Counters Are Clone Signals, Not Identity Proofs

WebAuthn Signature Counters Are Clone Signals, Not Identity Proofs A relying party can verify a valid WebAuthn assertion and still receive a counter value that adds no useful evidence about credential cloning. The signature proves possession of the credential private key for the signed assertion. The signCount field has a narrower role: when an authenticator maintains a usable signature counter, changes in that value can give the relying party evidence that the same credential may be active in more than one place.

Cybersecurity 19 Sep 2026 6 min read

WebAuthn Signature Counters Are a Clone Signal, Not a Session Guarantee

A WebAuthn assertion can carry a valid signature and still present an operational anomaly: its signature counter is not greater than the value stored after an earlier successful assertion. That condition is useful, but it is not equivalent to proof that a private key was copied, and it does not make the counter a replay-prevention mechanism. The signCount field sits inside authenticator data. A relying party receives that authenticator data as part of an assertion and verifies it together with the client data and signature. The counter can give the relying party evidence about authenticator state across successful ceremonies. Its security value depends on the authenticator’s counter behavior and on the relying party retaining the prior value correctly.

Cybersecurity 19 Sep 2026 6 min read

userfaultfd Write Protection Moves Memory Writes Behind a User-Space Fault Boundary

A thread can hold a writable virtual memory mapping and still block when it attempts to modify a particular page. Linux userfaultfd write-protect mode lets user space register a memory range, apply write protection to pages in that range, and receive a page-fault event when a protected page is written. The VMA can remain logically writable while page-table state creates a narrower interception boundary. This mechanism is not a general authorization system. It is a memory-fault control interface. Its security relevance comes from the placement of the decision point: a write can be suspended before the protected page changes, allowing a separate handler to record state, coordinate migration, preserve a snapshot boundary, or reject progress by leaving the fault unresolved.

Cybersecurity 19 Sep 2026 7 min read

SSH Host Key Continuity Is a Client Trust Boundary

SSH Host Key Continuity Is a Client Trust Boundary An SSH connection can negotiate strong encryption and still authenticate the wrong server. Encryption protects the transport after key exchange establishes its cryptographic context; it does not independently tell a client that the server key belongs to the intended host. That identity decision rests on host-key verification. For many interactive clients, the visible artifact is a known_hosts entry. The deeper security property is continuity: a client needs a trustworthy basis for accepting a host key now and for deciding whether a different key later represents legitimate rotation or an unexpected endpoint.

Cybersecurity 19 Sep 2026 9 min read

Signal Protocol Is a Cryptographic Layer, Not a Transport Protocol

Signal Protocol Is a Cryptographic Layer, Not a Transport Protocol A Go service can deliver messages over WebSocket, HTTP, WebRTC, MQTT, or a store-and-forward queue without any of those transports providing end-to-end encryption. Transport encryption such as TLS protects a connection between network peers. Signal Protocol addresses a different boundary: message content is encrypted at one endpoint and remains ciphertext until the receiving endpoint processes the corresponding cryptographic session. That distinction determines where Signal Protocol belongs in an application. The relay can authenticate accounts, route envelopes, retain undelivered ciphertext, and enforce quotas, but it should not need the conversation keys required to recover message plaintext.

Cybersecurity 19 Sep 2026 7 min read

OCSP Stapling Moves Revocation Evidence into the TLS Handshake

OCSP Stapling Moves Revocation Evidence into the TLS Handshake A TLS certificate can remain within its validity period after its issuer has marked it revoked. The certificate’s dates and signature do not encode that later status change, so a client that cares about revocation needs status information from another mechanism. OCSP provides signed status responses for identified certificates. OCSP stapling changes the delivery path: the TLS server obtains a response and sends that signed evidence to the client during the handshake.

Cybersecurity 19 Sep 2026 7 min read

OAuth mTLS Certificate Binding Moves Token Proof into the TLS Connection

OAuth mTLS Certificate Binding Moves Token Proof into the TLS Connection An OAuth access token can pass every syntactic and cryptographic check at a resource server and still be insufficient for access. With a mutual-TLS certificate-bound token, the server also needs evidence from the TLS connection: the client presenting the token must possess the private key corresponding to the certificate associated with that token. That changes the security boundary. A bearer token is usable by a party that obtains the token value, subject to the token’s other restrictions. A certificate-bound token adds a separate possession requirement tied to the TLS client certificate. The token and the private key become two pieces of the same authorization path.

Cybersecurity 19 Sep 2026 5 min read

no_new_privs Blocks Exec-Time Privilege Gain

A service may need to execute helper programs after it has accepted untrusted input. If one of those programs is set-user-ID, set-group-ID, or carries file capabilities, a normal execve() can cross a privilege boundary even when the calling process itself has no intent to acquire extra authority. Linux no_new_privs changes that transition: once set for a thread, later execve() calls cannot grant privileges that were absent from the caller at the point of execution.

Cybersecurity 19 Sep 2026 6 min read

memfd Seals Turn Shared Memory into a Kernel-Enforced Immutable Payload

Shared memory is efficient partly because two processes can observe the same storage without copying it. That property becomes a security problem when one side validates bytes and later consumes them while another side still holds authority to mutate the same object. Linux memfd sealing can narrow that race by making selected mutations fail in the kernel before the file descriptor crosses a trust boundary. memfd_create() creates an anonymous file and returns an ordinary file descriptor. The object can be sized, written, mapped, and transferred over a UNIX domain socket. With MFD_ALLOW_SEALING, the inode starts with an empty seal set, allowing the producer to add irreversible restrictions after population.

Cybersecurity 19 Sep 2026 7 min read

JWS Key Selection Is a Trust Decision, Not a Header Instruction

JWS Key Selection Is a Trust Decision, Not a Header Instruction A signed token can carry enough metadata to point a verifier toward a key. A JWS protected header can name an algorithm with alg, identify a key with kid, or, in profiles that permit them, carry or reference key material through parameters such as jwk, jku, x5c, or x5u. Those fields are useful for routing verification work, especially during key rotation.

Cybersecurity 19 Sep 2026 6 min read

IMA Appraisal Binds File Access to Integrity Metadata

A file can have ordinary read or execute permission and still fail an integrity check at the kernel boundary. Linux Integrity Measurement Architecture (IMA) appraisal can apply policy rules at selected hooks and require file content to agree with integrity metadata before the covered operation proceeds. This adds a content-integrity condition to access decisions without turning Unix mode bits or application authorization into integrity mechanisms. IMA contains related but distinct functions. Measurement records file state in an integrity measurement list and can extend measurements into a TPM. Appraisal evaluates a file against integrity metadata and can reject access when policy and enforcement mode require a valid result. Audit records security-relevant state. A deployment that only measures files gains evidence about observed state; it does not automatically gain the blocking behavior associated with appraisal.

Cybersecurity 19 Sep 2026 6 min read

HTTP/1.1 Framing Disagreement Creates a Request Smuggling Boundary

HTTP/1.1 Framing Disagreement Creates a Request Smuggling Boundary An HTTP/1.1 connection can carry multiple requests in sequence. Each recipient therefore has to decide exactly where one request ends before it can parse the next. In a direct client-to-origin connection, one parser makes that decision. In a deployment with a reverse proxy, gateway, load balancer, cache, or other intermediary, the same byte stream can cross several parsers before reaching application code.

Cybersecurity 19 Sep 2026 4 min read

HSTS State Closes the First-Request Downgrade Window

HSTS State Closes the First-Request Downgrade Window A site can redirect every HTTP request to HTTPS and still expose a gap before that redirect arrives. The browser has already sent an HTTP request across the network. An active intermediary can alter that exchange, suppress the redirect, or keep the client on plaintext HTTP. HTTP Strict Transport Security (HSTS), defined by RFC 6797, changes where the decision occurs. After receiving a valid Strict-Transport-Security header over a secure connection, a conforming user agent records policy state for the host. A later HTTP navigation to that host is converted to HTTPS locally before the insecure request is emitted.

Tech 19 Sep 2026 6 min read

Hacker and Developer Forums Serve Different Technical Workflows

A developer asking why a PostgreSQL query ignores an index needs a different community from a security researcher comparing exploit mitigations or an Android developer debugging a device-specific kernel problem. They may all be called forums, but their information systems work differently. Some communities optimize for a precise question and a reusable answer. Others preserve long discussions, attach conversation to a software project, publish security research, or rank links that engineers consider worth discussing. Choosing the right venue changes both the quality of the response and how useful the discussion remains months later.

Cybersecurity 19 Sep 2026 8 min read

GrapheneOS Security Boundaries: Android Hardening, the Baseband, and IMEI

GrapheneOS can change how Android isolates applications, how privileged services are exposed, how the operating system is verified at boot, and how much authority Google Play receives. It cannot turn every property of a phone into an operating-system setting. IMEI is a useful example of that boundary. GrapheneOS explicitly states that changing the IMEI is not possible on a production device and that the operating system cannot add support for it because the hardware does not support that operation. The distinction is architectural: Android controls a large software stack, but the cellular modem and device identity mechanisms are not ordinary application data stored inside the Android user space.

Cybersecurity 19 Sep 2026 6 min read

fscrypt Policies Bind Directory Trees to Filesystem Encryption Keys

A directory can remain fully visible in a mounted Linux filesystem while its regular-file contents and filenames are unusable without a particular key. With fscrypt, that boundary is attached to filesystem objects rather than created by mounting a second encrypted filesystem. An encryption policy assigned to an empty directory is inherited by regular files, directories, and symbolic links created beneath it. The property is narrower than full filesystem secrecy. fscrypt encrypts file contents and filenames, but most filesystem metadata remains visible, and ordinary permission checks continue to define who may access objects once the relevant key is present. Encryption policy and access control are therefore separate boundaries.

Cybersecurity 19 Sep 2026 7 min read

fs-verity Binds Read-Only File Reads to a Merkle-Tree Digest

A file can be stored on media that is less trusted than the process consuming it. Making that file read-only through ordinary permission bits does not prove that the bytes later returned from storage are the bytes that were approved earlier. Linux fs-verity addresses that narrower integrity boundary for supported filesystems by binding reads from an enabled file to a Merkle tree and a stable file digest. The mechanism has two distinct security roles. The kernel verifies file data against the Merkle tree during reads. A separate policy must establish that the resulting fs-verity digest is the digest that the system intended to trust. Treating those roles as one guarantee overstates what the filesystem feature provides.

Cybersecurity 19 Sep 2026 6 min read

Fetch Metadata Headers Define a Server-Side Cross-Site Request Boundary

A browser can send an authenticated request to a site from a document hosted somewhere else. Cookies may accompany that request according to their cookie attributes, while the same-origin policy can still prevent the initiating page from reading the response. For a server, that distinction matters: blocking response access does not necessarily stop a cross-site request from reaching an endpoint. Fetch Metadata adds request context to this boundary. Supporting user agents attach Sec-Fetch-* request headers that describe relationships and request properties the server can evaluate before application logic performs a sensitive action. A policy can reject a request because it is cross-site, while preserving selected navigation or public-resource flows.

Cybersecurity 19 Sep 2026 7 min read

fanotify Permission Events Put File Access Behind a User-Space Decision

A process can pass ordinary filesystem permission checks and still wait before its file operation completes. Linux fanotify permission events let a monitoring group intercept selected operations and require a user-space listener to return an allow or deny response. The mechanism inserts a synchronous decision point into the access path rather than merely reporting activity after it occurs. That distinction makes fanotify useful for security products that need content inspection or policy evaluation close to file access. It also creates a dependency that ordinary notification systems do not have: the kernel may be holding another process at a permission event while user space decides its fate.

Cybersecurity 19 Sep 2026 6 min read

DPoP Binds OAuth Tokens to Client Keys, Not to Client Identity

A bearer access token normally authorizes whichever party can present its value to a resource server. Copying the token can therefore move its authority away from the client that originally received it. OAuth 2.0 Demonstrating Proof of Possession, or DPoP, changes that property by binding a token to a public key and requiring a signed proof from the corresponding private key during presentation. That binding narrows one important failure mode, but it does not turn the key into a universal client identity. DPoP is an application-layer sender-constraining mechanism. Its guarantees depend on the token binding, proof validation, replay policy, TLS, and the security of the client execution context.

Cybersecurity 19 Sep 2026 7 min read

DNS Rebinding Preserves Web Origin While the Network Destination Changes

DNS Rebinding Preserves Web Origin While the Network Destination Changes A browser can treat two requests as same-origin even when the TCP connections behind them terminate at different IP addresses. The origin model is built from the URL scheme, host, and port. DNS resolution is a network operation beneath that identity. If a hostname resolves to one address and later resolves to another, the browser-facing origin can remain unchanged. DNS rebinding exploits that separation. An attacker-controlled hostname can initially resolve to an attacker-controlled server that delivers script, then later resolve to an address reachable from the victim’s network. Subject to browser, resolver, transport, and target-service behavior, subsequent requests for the same hostname can then cross a network boundary without becoming cross-origin in the browser’s origin model.

Cybersecurity 19 Sep 2026 6 min read

CSP Nonces Move Script Trust from Hostnames to Response Markup

CSP Nonces Move Script Trust from Hostnames to Response Markup A script policy based only on hostnames answers a coarse question: which network locations may supply JavaScript? That boundary becomes weak when an allowed origin hosts user-controlled files, JSONP-style endpoints, legacy script resources, or other content that was never intended to receive execution authority. A nonce-based Content Security Policy changes the unit of trust. Instead of granting execution authority to every script fetched from an approved host, the server places an unpredictable value in the policy and on the specific <script> elements authorized for that response. The browser checks that relationship before executing those elements.

Cybersecurity 19 Sep 2026 7 min read

CSP Nonces and strict-dynamic Shift Script Trust to the Bootstrap Boundary

A Content Security Policy can contain a long list of approved script hosts and still expose more execution authority than its author intended. A host source such as https://cdn.example.net authorizes matching script resources from that origin; it does not express which individual response or which application decision is trusted. When a permitted host serves user-controlled files, legacy JSONP endpoints, or another executable resource outside the application’s intended set, the host boundary can become too broad.

Cybersecurity 19 Sep 2026 6 min read

COOP and COEP Turn Cross-Origin Isolation into a Document-Group Boundary

COOP and COEP Turn Cross-Origin Isolation into a Document-Group Boundary A web page can be same-origin with its own application code while still maintaining relationships with cross-origin popups, frames, workers, and resources. Those relationships matter when a browser decides which documents can occupy the same browsing context group and which capabilities can be exposed safely. Cross-origin isolation changes that arrangement through two response policies with different jobs. Cross-Origin-Opener-Policy (COOP) controls top-level opener relationships and browsing context group switches. Cross-Origin-Embedder-Policy (COEP) constrains the cross-origin resources a document and its descendants may load. Used together in the configuration required for isolation, they establish a browser-enforced boundary that is broader than the same-origin policy alone.