DEV Community: StarkMan

Archivematica's 1,061 title matches make preservation control planes worth inventorying

StarkMan — Sun, 01 Nov 2026 00:00:38 +0000

Archivematica's 1,061 title matches make preservation control planes worth inventorying

Archivematica manages digital preservation workflows: transfers, ingest, normalization, storage and archival packages. A dashboard that controls those workflows can approve transfers, expose metadata and connect to a separate Storage Service. The system is not a passive archive viewer. It is a control plane over the evidence and files an institution has promised to preserve.

On 2026-10-31, a count-only ZoomEye query returned zero matches for app="Archivematica" and 1,061 for title="Archivematica". The title query ran at 23:44:58 UTC and the application query at 23:44:57 UTC. Both used sub_type=all, page 1 and page size 1. The zero application result is a fingerprint miss, not a claim that no dashboard exists. The 1,061 title matches can include project pages, training material and user portals.

The documentation distinguishes the Dashboard from the Storage Service API. Both require authentication, and the Dashboard uses Django's cookie-based user authentication for its web session. API calls can use a username and API key, with an Authorization header carrying the key or, in the older documented pattern, query parameters. The query-parameter form creates a logging risk. Prefer the header form, enforce TLS, and make sure reverse-proxy logs do not retain credentials.

Inventory both services. The Dashboard may be used by archivists and preservation staff. The Storage Service may have its own API and credentials and may connect to object storage, network filesystems or remote locations. A dashboard that is private does not automatically make a storage endpoint private. A storage service that is reachable from an application network should still authenticate callers and restrict administrative operations.

Test roles with a low-privilege account. Confirm who can create a transfer, approve an ingest, change processing configuration, download a package or delete an object. The documented API is designed for automation, so a CI job or preservation integrator may hold a powerful key. Give that key a named owner, store it outside the repository, rotate it on staff or vendor changes, and review recent actions. Avoid sharing one key across scripts.

Preservation systems often hold restricted material. Accession records, donor agreements, personal information and embargoed files may not belong in a public finding aid. Review the metadata export paths and the object download URLs, not only the Dashboard page. A public preservation index or thumbnail can disclose the existence of a collection even when the package itself is protected.

Availability is a security property for preservation. A dashboard exposed to the internet increases the chance of credential attacks, automated scanning and accidental configuration changes. Restrict administrative access to a trusted network or identity-aware proxy, monitor failed logins, and test restoration of the configuration as well as the content. An outage in the control plane may stop preservation processing even when the stored packages remain intact.

The 1,061 title matches are a candidate set, not a list of exposed archives. An owning organization should confirm the service, map Dashboard and Storage Service endpoints, and compare anonymous, staff and administrator behavior. Archivematica protects digital material over long periods. Its own administrative path needs the same care as the collections it preserves.

References

Triage playbook for suspected CVE-2026-105482 exploitation

StarkMan — Sat, 31 Oct 2026 20:40:37 +0000

Triage playbook for suspected CVE-2026-105482 exploitation

An alert about CVE-2026-105482 may arrive as a scanner finding, a runtime-version report, or a suspicious DNS request. The first task is not to label every Node.js system compromised. The team needs to establish whether an affected runtime received an attacker-controlled hostname and acted on a truncated resolution result.

Establish the technical facts

The flaw affects Node.js dns.resolve*() and dns.reverse(). A hostname containing a NUL byte can be silently shortened at the c-ares boundary. The resolver then returns records for the shorter name without an error. The Node.js advisory calls the issue an incomplete fix of CVE-2026-48930, which covered dns.lookup() and host options in net and tls.

The issue is rated high severity. The GitHub Advisory Database lists CVSS 3.0 score 7.4 with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. That describes a network-accessible condition with high attack complexity and potential confidentiality and integrity impact.

Confirm the runtime

Node.js 22.x, 24.x, and 26.x are affected before the fixed releases. The patched versions are Node.js 22.23.4, 24.22.1, and 26.12.1. Check the actual process and package version from the deployed host, container, or serverless environment. A dependency scanner that reports an application library is not evidence that the runtime is patched.

Record where the process runs, who owns it, what it exposes, and whether it can make outbound network connections. A build tool with no untrusted hostname input is lower priority than a customer-facing URL fetcher, but it may still have access to internal build networks.

Trace the vulnerable sequence

Look for request handlers and integration jobs that accept a hostname or URL. Determine whether the value reaches dns.resolve*() or dns.reverse() and whether a policy check happens before or after that call. The important question is whether the application validates the full string but resolves the truncated one.

Review logs for control-character encoding, suspicious suffixes after a NUL, and DNS records returned for a shorter name than the policy object. Compare the approved hostname with the address used by the outbound connection. Preserve the original request representation before any log normalizer removes the byte.

Containment

If a vulnerable application path is confirmed, restrict outbound access to required destinations. Block metadata, loopback, link-local, private networks, and administrative endpoints where the application has no legitimate need for them. Disable or pause the affected workflow if the business impact is acceptable.

Upgrade to a fixed Node.js release and rebuild the artifact. Rotate credentials only if the evidence shows that a protected secret was exposed or used. A hostname bypass alone does not prove credential theft. Reset sessions or tokens when suspicious responses or unexpected outbound traffic provide a reason to do so.

Exposure evidence and limits

The ZoomEye Search app="Node.js" returned 5,537,125 product matches during this review. The CVE Filter vul.cve="CVE-2026-105482" returned 0. The product count is not a vulnerable-asset count, and the zero Filter result does not override the vendor advisory. Use both as inventory context, not as incident proof.

Evidence to collect

Preserve the application version, runtime version, deployment revision, and image digest. Collect request and DNS logs that cover the suspected time range, along with proxy and network-flow records for outbound destinations. Record the exact query used in ZoomEye and the observation time if asset data is part of the investigation.

Keep a timeline that separates a scanner match, an affected runtime, a vulnerable code path, and an actual security action. Those are different levels of confidence. A system can match the runtime product and still have no exploitable workflow.

Recovery criteria

The runtime upgrade is deployed to every affected artifact. The vulnerable DNS path rejects NUL input or canonicalizes it before resolution. Outbound policy checks the resolved address. Tests cover the complete request path, and monitoring records a mismatch between the approved name and the connection target.

After those steps, retain a review item for application logic that still treats a boolean hostname check as authorization for a later network action. CVE-2026-105482 can be fixed in the runtime, but that architectural assumption can survive the patch.

References

Upgrade and Verify Netty 4.1.137 or 4.2.17

StarkMan — Sat, 31 Oct 2026 17:20:27 +0000

Upgrade and Verify Netty 4.1.137 or 4.2.17

A version change in the build file is only one part of remediating CVE-2026-75595. The fixed release must reach the packaged application, and the deployed TLS listener must keep its intended client-authentication policy. The affected io.netty:netty-handler ranges are up to 4.1.136.Final, and 4.2.0.Final through 4.2.16.Final. The patched releases are 4.1.137.Final and 4.2.17.Final.

Choose the correct release line

Select the fixed version that matches the application's supported Netty branch. Do not downgrade a newer major line merely to satisfy a version string. Check the framework's compatibility notes and its dependency-management rules before changing the version.

If the vulnerable package arrives through a platform BOM, update the BOM or add a narrowly scoped constraint. If the application shades Netty, rebuild the shaded artifact. If a container base image supplies the class, rebuild the image from a patched parent rather than copying a replacement class into the running filesystem.

Inspect before and after

Before the change, record the resolved netty-handler version and the service owner. After the build, inspect the artifact again:

mvn dependency:tree -Dincludes=io.netty:netty-handler

For Gradle, use:

./gradlew dependencyInsight --dependency netty-handler --configuration runtimeClasspath

Compare the output with the affected ranges. Then verify the file inside the deployable image or executable jar. The source build can be correct while a stale layer or alternate class path leaves the vulnerable copy in production.

Test mTLS behavior

Prepare test clients for the intended SNI route, a missing or unrecognized SNI, and the fallback context. Verify that a client with a valid certificate reaches the protected service when expected. Verify that a client without a certificate is rejected. Use controlled test credentials and avoid reading production client keys.

Review the default SslContext as part of the deployment. If it permits clients without certificates and there is no application-level peer-certificate check, treat that configuration as a separate access-control finding, even after the library is patched.

Roll out with observable checks

Use a canary or small service slice to compare TLS handshake outcomes before and after the upgrade. Track certificate-authentication failures, TLS parsing errors and route-selection failures. A jump in valid-client failures can indicate a certificate or SNI mapping problem. A drop in required-auth rejections can indicate that policy changed.

Do not use a successful health check as proof that mTLS works. Health endpoints may use a different listener or context. Add a dedicated test that exercises the same SNI mapping and client-auth settings as the protected workload.

Handle the fallback as a temporary control

If the upgrade is delayed, review whether the default context can require a client certificate. That change can remove the permissive fallback condition described by the advisory. It may break clients that rely on the fallback route, so test it and keep the library upgrade in the remediation plan.

The temporary control does not fix the parser error. It changes the surrounding policy so a selection failure is less likely to grant access. Record the residual affected version until the dependency is updated.

Close the finding with evidence

A complete record contains the application identity, resolved fixed version, packaged artifact hash, deployment time and mTLS test result. The owner should be able to show that the affected range is gone from the running artifact and that the protected route still requires the intended certificate.

ZoomEye Search app="Netty" returned 505 product fingerprints on 2026-10-31, with a CVE Filter result of 0. Those values support external discovery but do not replace the rollout evidence. Use them to look for forgotten public services, while the upgrade record remains the basis for closure.

References

SuiteCRM exposes a role-and-group review problem, not one product verdict

StarkMan — Sat, 31 Oct 2026 14:00:48 +0000

SuiteCRM exposes a role-and-group review problem, not one product verdict

A CRM login page is an entry point to customer records, sales activity, support cases, and sometimes integration credentials. SuiteCRM deployments can combine direct user roles, security groups, record assignments, and two-factor authentication. Discovery should therefore produce an owner and a permission review, not a label that every visible instance is vulnerable.

A ZoomEye count-only measurement on October 31, 2026 at 06:44 Beijing time used page 1, page size 1, and sub_type=all. app="SuiteCRM" returned 23,040 matches and title="SuiteCRM" returned 11,426. These are separate visible fingerprint observations. They do not show that any matching instance has weak authentication or exposed customer data.

Treat both queries as evidence

The app query identifies a larger candidate set in this sample. The title query finds a different set of pages and can catch custom branding or a deployment whose app signature is absent. Neither set is authoritative for an owned inventory, and neither count should be added to the other. Some assets may appear in both results, while others appear in only one.

The useful follow-up is an ownership match. Compare hostnames against DNS zones, certificate issuance, cloud accounts, and the organization's service catalog. A host outside all known inventories may be a shadow deployment or simply a third-party page that mentions the product. Resolve that ambiguity without touching someone else's account.

Review roles and security groups

SuiteCRM's administrator documentation explains that roles define access and security groups assign users to records. Direct user roles can take precedence over group roles. That interaction makes a simple review of one role matrix insufficient. Test users with group membership, direct assignment, multiple roles, and no role.

Check module access, field-level permissions, record ownership, export rights, and administrative functions. Review users who can import or export large record sets. Export capabilities can move customer data outside the CRM even when the screen-level permissions look correct. Review API and integration accounts separately from interactive users.

Authentication controls matter as much as record permissions. Confirm the availability of two-factor authentication, password policy, account recovery, and session termination. Check that administrator accounts are not shared. If SSO is configured, verify the mapping of identity-provider groups to SuiteCRM roles and how a removed group changes access.

Validate the public boundary

If the CRM is meant to be public, inspect the login page, recovery flow, and supported APIs from outside the network without attempting authentication. If it is meant to be private, confirm that the public route closes and that the old hostname does not remain reachable through a direct IP, alternate port, or stale proxy rule.

Look for exposed diagnostic files, backup archives, installation paths, and source maps as part of an owned assessment. Do not use a public fingerprint count as authorization to enumerate another organization's site. Keep screenshots and evidence free of personal data.

Build an evidence record

For each discovered deployment, record the hostname, owner, environment, product version, role model, security-group model, identity provider, API integrations, backup owner, and last access review. Assign a completion check for each control. A role review is not complete until a test user sees exactly the intended records and an exported test confirms the field boundary.

ZoomEye can shorten the time needed to find forgotten public deployments. The permission model determines what those deployments could expose after authentication. A strong inventory connects the two.

Conclusion

SuiteCRM's 23,040 app matches and 11,426 title matches describe discovery populations, not security outcomes. The next step is to separate owned assets, map direct roles and security groups, test record and export boundaries, and close unintended public routes. That evidence is more useful than a larger count alone.

References

A Lax Cookie Is Not a CSRF Token

StarkMan — Sat, 31 Oct 2026 10:40:13 +0000

A Lax Cookie Is Not a CSRF Token

The SameSite cookie attribute is a useful browser-side control. It limits when cookies are attached to cross-site requests. It is also easy to treat as a complete anti-CSRF design, especially when a framework silently defaults a session cookie to Lax. That treatment leaves gaps in applications that change state through top-level navigation or expose cookie behavior through multiple sites.

Same-site and same-origin are different

The cookie specification compares sites, which are derived from the registrable domain and scheme, not origins, which also include host and port. A page on app.example.com and a page on login.example.com may be same-site while remaining different origins. A cookie policy based on "same-site" therefore does not automatically protect an endpoint from another host in the same organizational domain.

SameSite=Lax sends cookies for some top-level navigations and same-site requests. It blocks many cross-site subresource requests, but it is not a rule that all unsafe methods are protected. An application can still expose a state-changing flow through a top-level GET, a redirect, or a site relationship the designer did not include in the threat model.

Use the cookie mode as one layer

MDN recommends Strict where the application can tolerate it, or Lax as a practical default. None requires Secure in modern browser behavior and should be reserved for a documented cross-site embedding need. HttpOnly protects the cookie from ordinary script access, but it does not stop a browser from sending the cookie when the request conditions allow it.

The server still needs a request-authentication strategy for sensitive operations. That can include a synchronizer token, an origin or referrer check with a documented fallback, or a design that requires an explicit user action and a fresh authorization check. Choose the control that matches the application's navigation and embedding requirements.

Test the real browser path

Create two test sites and try the operations that matter: a form POST from another site, a top-level GET that a server treats as a state change, an iframe workflow, and a redirect chain. Inspect the Set-Cookie header and the browser's cookie state. Do not rely only on a command-line client, which does not implement the browser's site rules.

Verify the result from both the application and the authorization layer. A request that reaches the server with a valid session is not automatically an authorized action. A request that arrives without a cookie should fail at the first authentication check, and a request with a cookie from a sibling site should not bypass the server-side policy.

Deployment details

Set cookie attributes consistently across environments. Check that proxies do not rewrite Set-Cookie, that TLS termination preserves Secure, and that a subdomain migration does not change the registrable site boundary. Inventory cookies used by authentication, preferences, and embedded tools; a single unprotected preference cookie can leak information even when the session cookie is strict.

Use a small test matrix in the release checklist. Include a cross-site navigation, a cross-site form submission, an embedded iframe, and a same-site sibling host. Record the browser version and the observed header. If the application depends on a top-level callback, test whether Lax still allows the cookie and whether the callback can be abused to change state.

SameSite reduces a class of browser-driven requests. CSRF protection remains a property of the endpoint, its authorization logic, and the workflow that accepts state changes. The two controls should be reviewed together.

References

Auditing Nginx client-IP trust when PROXY protocol meets RealIP

StarkMan — Sat, 31 Oct 2026 07:20:30 +0000

Auditing Nginx client-IP trust when PROXY protocol meets RealIP

A reverse proxy can make an application see the real client address, but the same feature can also make it believe an address that never connected. Nginx exposes this distinction through the HTTP RealIP module. The module changes the client address and optional port from a value supplied by another system. Its safety therefore depends on who is allowed to supply that value.

What the directives actually change

set_real_ip_from defines addresses that Nginx treats as trusted senders of replacement addresses. real_ip_header selects the source: X-Real-IP, X-Forwarded-For, or proxy_protocol. PROXY protocol is available only after it is enabled on the listening socket with the proxy_protocol parameter. Nginx's documentation also notes that the HTTP RealIP module is not built by default and must be enabled at compile time.

real_ip_recursive controls how a header chain is interpreted. With recursion off, a request from a trusted address has its client address replaced by the last address in the selected header. With recursion on, Nginx walks past trusted addresses and chooses the last non-trusted one. That behavior is useful behind a controlled chain of proxies. It is risky when the header can arrive from a network that includes clients, because a client can then become the author of its own apparent address.

The direct-listener mistake

A common design places Nginx behind a load balancer and trusts the balancer's subnet. The public listener on the load balancer accepts PROXY protocol or injects forwarding headers. The Nginx listener is supposed to accept traffic only from the balancer. If that listener is also reachable through a forgotten public interface, a direct client may be able to supply the same syntax.

Firewall rules must enforce the network assumption. Binding the listener to a private address is better than relying on a host firewall alone. A container deployment needs the check at the container network, the host network, and the upstream load balancer. A trusted source range should be as narrow as the actual proxy addresses or an operationally controlled subnet. Trusting an entire private range can include systems that should not set client identity.

Production checks

Start with the rendered configuration, not the template. Confirm which listen lines include proxy_protocol, which set_real_ip_from ranges apply in each server and location block, and whether real_ip_recursive is on. Then test from an untrusted host. Send a forged X-Forwarded-For header to the public edge and observe the address Nginx writes to logs. A forged value must not become the trusted client address.

Test a direct request to the backend listener as well. If the connection succeeds, treat it as a bypass even when the application itself checks a header. The application cannot recover a trustworthy address from a value that was never authenticated. Restrict the listener and confirm that the rejection comes from the network boundary, not from an application error page.

Logging also needs review. $remote_addr reflects the module's replacement, while $realip_remote_addr keeps the original sender address. Retaining both can separate the client address from the proxy address during an investigation. If logs feed access controls, alerting, or rate limits, document which variable each system uses.

Where IP trust is the wrong control

An IP address can support network policy, but it cannot replace user authentication. VPN egress addresses change, mobile networks share addresses, and proxy chains can alter what is observed. Administrative endpoints should still use strong authentication and server-side authorization. Rate limiting can use an address as a signal, but a shared address should not turn one client's actions into a blanket block or grant. Use account and device identity where the decision needs that identity.

A defensible Nginx deployment makes the trust boundary explicit: only approved proxies can connect, only approved fields can carry client identity, and direct access to the backend is blocked. The configuration should make that design visible to the next operator.

References

Mapping Apache NiFi data-flow interfaces before changing access policy

StarkMan — Sat, 31 Oct 2026 04:00:38 +0000

Mapping Apache NiFi data-flow interfaces before changing access policy

Apache NiFi sits on the path between data sources, transformations, and destinations. That position makes its user interface and REST API more than a monitoring convenience. They can expose flow definitions, processor configuration, connection metadata, and operational controls. An inventory is useful when it distinguishes an observed NiFi interface from a confirmed anonymous or vulnerable deployment.

Why the interface matters

NiFi's administration guide describes authenticated access, authorization policies, and the nifi.security.allow.anonymous.authentication setting. A secured instance does not allow anonymous authentication unless that property is enabled. Initial administrator setup determines who can manage users, groups, and policies. The REST API should use the Authorization header with an access token rather than sharing the browser session cookie pattern.

For a security review, look for three separate facts. Is the web interface reachable? Is anonymous access enabled? Which identity and policies apply after login? A banner or title alone does not answer the last two questions, and a login page does not prove that the deployment is secure.

A bounded ZoomEye observation

A count-only query was run on 2026-10-31. The query app="Apache NiFi" returned 6093 matches. A separate title query, title="NiFi", returned 6064. Both used page 1, page size 1, and sub_type=all. The result records fingerprint matches in the selected ZoomEye scope. It does not establish that every matching service is NiFi, that the interface is reachable without authentication, or that any matching deployment is vulnerable.

The app and title counts are close enough to support an inventory lead, but they should not be added or treated as distinct populations. They are two observations over the same broad asset scope. A team can use the app result as a starting search and then validate access control from its own asset records.

From count to decision

Build a deployment list that includes the public hostname, network zone, TLS termination point, NiFi version, authentication provider, and policy owner. Compare that list with the observed candidates. For each reachable interface, check the anonymous setting and the initial administrator path. Confirm that the management interface is not exposed to the general internet unless the architecture explicitly requires it.

Review the REST API separately from the browser UI. A reverse proxy may protect the UI while leaving an API path reachable. Check token handling, allowed source networks, CORS behavior, and request logging. Avoid printing access tokens in proxy logs or application diagnostics.

Authorization needs a data-flow view. A user who can change a processor can redirect data, and a user who can read a connection can inspect its contents. Map policy ownership to the people and services that actually need that control. Remove unused administrators after the initial setup.

Use the inventory without overstating it

A broad ZoomEye count is useful for finding a population that deserves a closer look. It is not a compliance result. Record the query, collection time, page scope, and count with the investigation. Then test the actual systems you control. That pairing turns a search observation into a defensible operational decision.

References

Wallabag Holds More Than Saved Pages

StarkMan — Sat, 31 Oct 2026 00:40:55 +0000

Wallabag Holds More Than Saved Pages

Wallabag stores articles, account details, API clients, and optional paywall credentials. An internet-facing reader can be a small service with a meaningful data set: saved pages may include internal documents, research notes, or links that reveal organizational interests.

Query result

On 2026-10-30, ZoomEye count-only queries used sub_type=all, page 1, and page size 1. app="Wallabag" returned 0. title="Wallabag" returned 1,544.

The app query did not match the selected fingerprint. The title result is a separate observation and may include login pages and other branded pages. It does not prove that any instance has sharing enabled or that a user's saved content is public.

Account and sharing controls

Wallabag's user documentation describes two-factor authentication and notes that administrators must enable the feature in the configuration before users can activate it. This is an application-level prerequisite. An organization that assumes every user has MFA should verify the instance setting and the per-user enrollment state.

The internal settings documentation describes privacy-related controls, including public sharing of articles. Review who can enable sharing and how a shared page can be revoked. Test with a disposable article and an unauthenticated browser. Confirm that a later revocation removes access, including from a cached direct URL where the application supports it.

Paywall credentials are especially sensitive. Wallabag's restricted-access documentation describes optional credentials for sites that require authentication. That credential store should not be readable by every user or by a database backup process with broader access than necessary. Rotate a test credential and confirm that the old value fails.

API clients

The user interface includes a place to manage API clients used by mobile apps and integrations. Each client should map to a known user and have a revocation path. A token saved in a phone backup or a browser extension is still part of the account boundary.

Review old clients after a device change. Remove a client that no longer has an owner. Test an API request after revocation. Keep OAuth access-token lifetime in mind when investigating a report of continued access. An issue dated after a token was issued does not automatically mean the old token was still valid at that time; the server logs need to show the actual session.

Network and backup checks

Find the public hostname and any alternate port or internal alias. The main login page may be protected by a proxy while the API route bypasses it. Test both with and without the expected session.

Check backup storage. Wallabag can use SQLite or another database, and the installation documentation describes database configuration parameters. The backup should be protected by the same access policy as the live data, including encryption and retention. A public title match can identify a possible instance; it cannot reveal whether an old backup sits beside it.

A focused review

Record the owned instances, version, MFA setting, sharing policy, API clients, and paywall credential ownership. Then test one legitimate share, one revoked share, one disabled user, and one revoked token. The result should show which controls fail closed and which rely on an operator remembering to change a setting.

The count is only an inventory clue. The security work is the smaller set of tests that connect a saved page to the person who should still be able to read it.

References

Start an ntfy server with deny-all access and a planned token model

StarkMan — Fri, 30 Oct 2026 21:20:14 +0000

Start an ntfy server with deny-all access and a planned token model

Self-hosted notification services often begin as a simple way to send a message. The deployment later holds deployment alerts, backup status, security events, and mobile push credentials. An ntfy server that still treats topic names as secrets is not ready for that role.

ntfy supports user and admin roles plus per-topic read and write permissions. Its documentation describes an access control list, access tokens, and a configuration option for a default access policy. The strongest starting point is auth-default-access: deny-all, followed by explicit user and topic entries. An allow-by-default server asks every topic owner to remember a setting, which is difficult to audit as the number of integrations grows.

Treat a topic as a resource

A topic name is not a password in a deny-all design. It identifies a publish and subscribe resource. The ACL should state which identity may read it, which identity may write it, and whether an anonymous sender is allowed. For a production alert channel, anonymous write access lets anyone with the URL inject false alerts or fill a notification queue. Anonymous read access can disclose operational details embedded in the message body.

Use separate topics for different trust boundaries. A backup agent does not need access to a security incident topic simply because both run in the same environment. A monitoring system may need write access to several topics and read access to none. A mobile client may need read access to one topic and no ability to publish. Model those relationships directly instead of creating a shared administrator token.

Plan token creation and retirement

ntfy tokens can be created through the command line or the web interface and can also be provisioned in server configuration. A token label should identify the workload or person, not a shared team name that survives staff changes. Keep a record of the issuing user, intended topic, permission set, creation date, owner, and retirement condition.

Prefer separate tokens for separate automation. If an agent token is copied into a chat message or included in a support bundle, the response can revoke one path without breaking every notifier. Set a review interval even if the server does not enforce expiry. A token with no known owner is a credential without an accountable custodian.

The server configuration may contain token values. Protect that file like any other secret store. Do not put it in a repository with broad developer access or print it in diagnostics. If tokens are provisioned declaratively, ensure the deployment pipeline uses encrypted secrets and limits who can read the rendered configuration.

Test from outside the trusted path

Use a signed-out or unprivileged client to attempt all four actions: publish to a protected topic, subscribe to it, publish to an unrelated topic, and read an administrative route. Record the expected denial. Then repeat with an authorized token for the specific topic and confirm that the scope is narrow.

Test the reverse proxy and TLS path separately. ntfy may be healthy on localhost while an upstream proxy adds a path prefix, forwards an administrator header, or exposes a metrics route. The application ACL does not compensate for a network device that bypasses it.

Review browser clients and mobile clients for cached messages. A revoked token stops new subscriptions, but it may not clear content already stored on a device. If a topic carried sensitive alert data, the incident response should include client-side data removal and an assessment of notification previews.

Make the default obvious

Configuration management should show the default access policy, the user list, and the ACL table in a reviewable diff. A temporary allow rule should include an expiry date and a change ticket. When an integration is removed, delete its token and its ACL entry. Leaving a dormant rule is how a simple notification service becomes an unmanaged message bus.

Alerting systems are part of the security control plane. A false message can trigger a destructive runbook, and a missing message can hide an outage. The practical standard is an explicit identity, an explicit topic, an explicit direction of access, and a known owner. That is more work than typing a memorable topic name. It also gives the team a defensible answer when someone asks who can read an incident channel.

References

Frigate exposure review: separate the camera UI from the unauthenticated API

StarkMan — Fri, 30 Oct 2026 18:01:02 +0000

Frigate exposure review: separate the camera UI from the unauthenticated API

Frigate is a network video recorder and object-detection service. It can expose a browser UI, an API, camera streams, and integration endpoints. A visible Frigate title is not enough to describe the exposure because the authenticated and internal listeners intentionally have different security properties.

The Frigate authentication documentation states that the authenticated UI and API use port 8971, while port 5000 provides internal unauthenticated UI and API access. Reverse proxies should use the authenticated port, and access to the internal port should be limited. The documentation also describes proxy-secret and trusted-proxy settings for deployments that terminate authentication upstream.

What the probe observed

The count-only ZoomEye probe ran on 2026-10-30 at about 17:46 UTC with sub_type=all, page 1, and a page size of one. app="Frigate" returned 5,092. title="Frigate" returned 10,541.

The title count can include unrelated pages and cannot show which port is exposed. A public login page at 8971 does not prove that port 5000 is reachable. Conversely, a title match from an internal network can still represent a sensitive camera system.

For an authorized inventory, record the host, TLS certificate, UI port, API path, proxy type, and whether authentication is required. Inspect only metadata needed to classify the service. Do not attempt to view camera streams or object-detection events on systems outside your ownership.

Test the network and proxy path

Confirm that the internal port is bound to a private network or container network and is not reachable from the public interface. If a reverse proxy handles authentication, verify the X-Proxy-Secret, trusted-proxy range, and identity headers together. A proxy that trusts a header from the wrong network can be bypassed.

Review the JWT secret, session length, user roles, and reset procedure. Changing the JWT secret invalidates existing tokens and is a useful containment step after suspected exposure. Ensure that reset credentials are not left in shared logs.

Test the public path with no session, a low-privilege user, and an administrator. Test the internal path from a permitted integration network and from a user workstation. The results should match the deployment diagram.

Frigate can provide useful camera visibility, but the same service can expose recordings and live streams. The review should prove which listener serves the internet and which listener is confined to integrations.

References

CVE-2026-109619 and the End-of-Life PHP Patch Problem

StarkMan — Fri, 30 Oct 2026 14:40:39 +0000

CVE-2026-109619 and the End-of-Life PHP Patch Problem

CVE-2026-109619 exposes a patch-management gap that often hides at the edge of an asset inventory. Supported PHP branches received fixed releases, but PHP 8.1 and older no longer receive normal project updates. Organizations still running those branches need a vendor backport, a source-build patch, or an upgrade. A policy that only watches current upstream versions can miss the older PHP worker behind a legacy application.

The PHP project fixed CVE-2026-109619 in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. It assigned CVSS v4.0 9.2. The flaw lets request-owned global state survive after its backing memory is freed, and a later request on the same worker can consume the stale state before normal initialization. The result can become remote code execution under suitable heap conditions.

The fixed version is branch-specific

PHP 8.2.35 is not a universal replacement for every other branch, and a higher-looking vendor package version does not automatically prove a backport. Record the functional branch, full version, package release, and upstream patch relationship. For supported branches, compare against the official fixed release. For a vendor backport, require a changelog or advisory that explicitly identifies CVE-2026-109619 or the source change.

A system can have both a current PHP binary and an old web-serving runtime. The command-line interpreter may be updated while Apache mod_php, FPM, or a container sidecar still uses the vulnerable package. Inventory the executable and SAPI that handle public requests. Check process start times after the update and verify that old workers were replaced.

End-of-life branches need an explicit path

The PHP advisory recognizes that PHP 8.1 and older are no longer normally maintained. Some distributions and long-term-support vendors provide backported fixes. The PHP security team also published minimal source backports for PHP 7.4, 8.0, and 8.1 for teams that build from source or lack an LTS vendor.

Those options require ownership and evidence. A source build should pin the patched source revision and record the build inputs. A vendor backport should have a supported package lifecycle and a test result for the specific runtime configuration. An application owner who cannot identify either path should plan an upgrade, not assume that the old branch is safe because it is common.

A clean platform response should avoid two mistakes. The first is treating end-of-life status as proof that no fix can exist. The second is treating any vendor update as proof that the vulnerable worker is gone. Both issues require runtime evidence.

Put PHP workers in the asset model

The asset should be the PHP-serving process, not only the host or application. Record the owner, environment, SAPI, branch, package source, container digest, public exposure, and process start time. Link the application, web server, and runtime owners because no single team may control the full chain behind CVE-2026-109619.

Use build metadata and software bills of materials to identify PHP inside application images and managed platforms. Include Apache and FPM configuration sources, loaded extensions, and deployment templates. Search for secondary services that embed PHP but are not represented as primary web assets.

A useful inventory can answer whether an old branch is externally reachable, whether it shares a worker pool with a public application, and whether a vendor update was installed after the last worker restart. Those facts are more actionable than a product label without a process owner.

Make rebuild and restart part of the fix

Package installation does not replace a running process. After updating, restart the web server and PHP process manager and confirm new child processes are serving traffic. Rebuild containers from the fixed base image and replace old instances. If the application copies its own PHP runtime, update that copy and rebuild every dependent image.

Keep a deployment proof for each environment. Record the fixed version, immutable image digest or package version, process start time, and public-route validation. For managed platforms, save the provider's runtime evidence and the application instance identity. A ticket that says the fleet was patched without identifying the serving process is weak closure evidence.

If patching is temporarily blocked, apply only the controls supported by the advisory. Set session.upload_progress.enabled=0 before request parsing and restart workers. On PHP 8.5, fatal_error_backtraces=0 blocks a confirmed path. Remove invalid or deprecated per-request diagnostics. Track these as exceptions with an owner and expiration because they do not fully mitigate the flaw.

Prevent the next blind spot

Monitor supported branches for security releases and separately track end-of-life deployments, vendor backports, and source-build patches. Alert when a public service reports a vulnerable branch or when a worker starts from an older image after an approved deployment. Test that alerts can identify the actual SAPI rather than a nearby command-line binary.

Review the inventory during application migrations. Legacy PHP often survives because an old component has no owner or is bundled into a deployment template. Give every runtime a lifecycle owner and a documented upgrade path. The policy should distinguish supported upstream releases, vendor-maintained backports, and unsupported runtimes with no patch source.

CVE-2026-109619 is a memory-safety emergency, but it also reveals a durable governance problem. The question is not whether one version string appears in a package list. It is whether every PHP process that serves traffic has a supported patch path and whether the old worker has truly been replaced.

Sources

Archive extraction needs a resource and path policy

StarkMan — Fri, 30 Oct 2026 11:20:28 +0000

Archive extraction needs a resource and path policy

Uploading an archive and extracting it later is a common application feature. It can also turn a small untrusted file into writes outside the destination, unexpected symbolic links, enormous disk use, or a denial of service. The extraction library is only one part of the control. The application needs a policy for paths, link types, size, file count, processing time, and the identity that handles the result.

Path traversal is the best-known failure: an archive member contains ../ segments and the extractor joins it to a destination without checking the resolved location. Symbolic links create a different problem. A link inside the archive can point to a sensitive path and a later member can write through it. Absolute paths, hard links, device nodes, and repeated names add more cases. A file name check that only removes .. substrings is not a sufficient design.

Validate before extraction, then validate again

Inspect the member list before writing anything. Reject absolute paths, parent traversal, duplicate names where they create ambiguity, and unsupported link or device types. Normalize each member path and confirm that it remains under the intended root. Check both the lexical path and the resolved filesystem path, because an existing symlink can change the meaning of a later join.

Extraction should happen under a fresh directory that the application controls, ideally in a disposable worker with a writable quota and no access to secrets or broad host mounts. Do not extract directly into the application's code directory or a shared upload directory. Keep ownership and mode bits under application policy rather than trusting archive metadata.

Python's tarfile documentation provides extraction filters that limit dangerous functionality. Current versions can use a data filter, and the documentation explicitly notes that even a filter is not a complete answer for live, untrusted data. Check the runtime version and set the policy explicitly when the default is not sufficient. Equivalent checks are needed for ZIP and other formats.

Bound the work, not only the bytes

A compressed file can expand far beyond its upload size. Set a limit on compressed bytes, uncompressed bytes, member count, individual file size, total extraction time, and the number of nested archive layers you will process. Count bytes as they are written rather than trusting the declared size in the archive header. Stop the worker when a limit is exceeded and remove the partial output according to a defined cleanup policy.

The CPU and memory used to validate names and decompress data are part of the attack surface. A scanning process that follows links or opens files to determine their type can itself become a gadget. Run the parser with reduced privileges, avoid unbounded recursion, and keep the processing queue isolated from the web process.

Make the result explicit

After extraction, enumerate the resulting files again. Confirm that the real paths remain under the worker root and that the application did not create links to places it cannot safely serve. Store a manifest of names, sizes, hashes, and content types. If the application converts or scans the files, use a new output directory rather than modifying the uploaded package in place.

Test the following cases in a non-production worker:

a normal archive with nested directories
an absolute member name
parent traversal in the stored name
a symbolic link to a file outside the destination
a hard link with an unexpected target
two members with names that normalize to the same path
a highly compressed file that exceeds the output limit
a corrupt archive that fails partway through extraction

The useful control is not a single regex. It is a small, isolated extraction service with explicit path validation, hard resource limits, a defensible file policy, and observable failure. Once those pieces are in place, an archive upload becomes a managed input instead of a request to run the server's filesystem operations.

References

[1] Python tarfile extraction filters

[2] OWASP File Upload Cheat Sheet

[3] OWASP testing guide, malicious file uploads