DEV Community: andreagomez

Auditing an Arch endpoint after a suspicious AUR install

andreagomez — Sat, 07 Nov 2026 15:25:14 +0000

Auditing an Arch endpoint after a suspicious AUR install

A malicious install script changes the incident question. The first question is not simply whether the package was removed. It is whether the scriptlet executed, what privileges it had, and which credentials or network paths were reachable from that host. The yyay report says the malicious command ran from a top-level install-scriptlet line and could execute downloaded code as root during installation or upgrade.

That makes a light cleanup risky. If the command ran, deleting the package may remove evidence while leaving a stolen key, a modified service, or a remote-access path in place. The endpoint review should preserve the package record and the surrounding build evidence before the team changes the machine.

Start with package identity and timing

Record the exact package name, version, install time, build user, and source revision. Save the PKGBUILD, install script, local patch files, and any package artifact still on disk. The Arch PKGBUILD(5) manual explains the install-script relationship, while makepkg(8) describes the local build workflow that produces the package. The mail-list scan supplies the specific command pattern that made yyay dangerous.

pacman -Qm lists foreign packages that do not exist in the configured sync repositories. pacman -Qo can identify the package that owns a file, and pacman -Qkk checks installed files against the local package metadata. These commands help build a timeline. None of them proves whether an install-script command reached the network, so pair them with the configured pacman log, shell history, process telemetry, and systemd records.

If the host has a package cache or build workspace, preserve it before cleanup. A local .pkg.tar.zst can contain the install script and show what was actually installed. Build directories can also contain fetched sources and logs. Timestamps should be interpreted in the host's local timezone and converted carefully when compared with the public report.

Inspect package execution as well as package names

The known package name is a useful lead, but the broader search should cover behavior. Look for shell processes that fetched a remote script and piped it into an interpreter. Review outbound proxy and DNS logs for the path described in the maintainer scan, including archive-wrapper traffic that may look more ordinary than a direct download.

Check for new system services, scheduled jobs, shell profiles, package-manager hooks, and changes to SSH configuration. The maintainer scan warned that the remote script was not fixed and could change, so a later copy of the URL may not match what ran during the incident. Preserve the response if the organization has it. If not, record that the payload content is unknown.

The host may also contain new package activity. A root-level script can modify package state, add files, or run commands under multiple users. Compare package lists, install-script files, ownership changes, and recent logins before deciding that the removal step was complete.

Decide whether to clean or rebuild

Cleaning is reasonable when the team can show that the package was downloaded but never installed, or when package records and telemetry establish that the suspicious scriptlet did not execute and no related changes occurred. That conclusion needs evidence, not a filename match.

A host that ran a top-level scriptlet as root should be handled as a potential compromise. Preserve evidence, isolate it from production credentials, and rebuild from a trusted image when the scope is uncertain. Rotate credentials that were readable on the host, including SSH keys, package-service tokens, cloud credentials, and browser or developer sessions. Review AUR and Git push activity under those credentials.

For a fleet, use one incident record per host. Store the package name, version, install time, user, evidence source, execution conclusion, cleanup action, credential rotation, and final owner. Do not merge a package inventory finding with a confirmed execution finding. They have different consequences.

Verify the endpoint inventory

The public report did not establish how many systems installed the lookalike packages. The team therefore cannot use its own package list as a complete count unless the list covers every relevant host and user. Include developer laptops, build runners, jump hosts, and any system where AUR access may have been enabled outside the normal configuration baseline.

Alerting rules should cover future changes as well as this package. Flag any new .install file, network command in a package lifecycle file, untrusted URL in a source entry, new maintainer identity, and package name edit distance from an approved baseline. Route the alert to the host owner with a clear decision: block, review, or approve.

What ZoomEye can and cannot show

ZoomEye can show public assets that mention the AUR, not the package state of an Arch endpoint. A query for http.body="Arch User Repository" returned 268 public assets in an all-scope observation on 7 November 2026. Use that as an ownership and awareness signal. It cannot locate yyay, prove that an install script ran, or count victims.

The strongest workflow combines both views. Use public evidence to find teams, services, and documentation connected to AUR workflows. Use endpoint evidence to decide what actually ran. The second source is the one that supports containment and recovery.

References

Caching OAuth introspection results needs a revocation budget

andreagomez — Sat, 07 Nov 2026 12:00:44 +0000

Caching OAuth introspection results needs a revocation budget

A resource server that sends every access token to an introspection endpoint pays a network round trip for each request. Caching looks like an obvious optimization. The cache also becomes a local statement that a token is still active, and that statement can outlive a revocation decision at the authorization server.

OAuth 2.0 Token Introspection returns an active value and may return metadata such as scope, client identifier, subject and expiry. The resource server must treat a missing or malformed response as an error, not as an inactive token. A timeout is not proof that access should be denied, but it is also not evidence that access should continue.

Put a ceiling on every entry

Cache a successful active result only until the earlier of the token's exp value and a small configured TTL. A revoked token remains revoked at the authorization server, but the cache can continue to authorize it until the entry expires. The TTL is therefore a revocation-delay budget, not a generic performance setting.

Do not use a single long TTL for every client. High-value administrative scopes can use a shorter budget than read-only application scopes. If the authorization server provides signed introspection responses, verify the issuer, audience, signature and timestamp before caching the claims. A JWT wrapper does not remove the need for freshness.

Distributed resource servers need a coherent cache policy. Two pods with different TTLs can disagree about the same token for a visible interval. Use a shared invalidation path for emergency revocation or accept the documented delay and expose it in the service level objective.

Test the failure modes

Measure the time from revocation to rejection at each resource server. Repeat with the introspection endpoint unavailable, with a malformed response and with a token whose expiry is shorter than the cache TTL. Confirm that the resource server fails in the direction the application expects.

Record token identifiers in logs only in a protected, non-reversible form. Do not persist full introspection responses, which can contain user and client metadata. Keep enough fields to explain the decision without creating a second credential store.

The cache is useful when its lifetime is explicit. The policy should state how much revocation delay is acceptable, who can shorten it during an incident and how every resource server enforces the same ceiling.

References

AnythingLLM exposure depends on which user mode is running

andreagomez — Sat, 07 Nov 2026 08:43:43 +0000

AnythingLLM exposure depends on which user mode is running

AnythingLLM combines document retrieval, chat and agent workflows. The security boundary changes significantly between a desktop or single-user installation and a Docker deployment with multi-user mode. A public scan can identify the product, but it cannot tell which mode is active from a title alone.

Two counts and a strong fingerprint

On 2026-11-07 UTC, page-one count-only ZoomEye probes with sub_type=all returned 7,787 matches for app="AnythingLLM" and 7,435 for title="AnythingLLM". The close counts provide a useful application fingerprint, but they do not establish authentication state. The result can include internet-facing instances, landing pages and deployments behind different access controls.

The product's security documentation warns that a single-user instance without a password or multi-user setup can be reachable by anyone who knows the URL. Multi-user mode adds accounts and roles, but the deployment still needs an external access decision for any audience beyond a trusted internal group.

Treat the API key as instance authority

The developer API uses an API key, and the documentation states that anyone with the key can use it. That is a broad authority claim. Store the key in a secret manager, restrict who can read it, rotate it after suspected exposure and avoid embedding it in a public client. Review the instance's API documentation endpoint as part of the deployment, because the endpoint list reveals the available management and data operations.

The official security policy also treats unrestricted developer API access as part of the product's design rather than a fine-grained tenant control. If the organization needs per-user authorization, it should not assume the shared API key supplies it.

Review the data plane

Document collections and workspaces can contain sensitive material. Confirm who can create workspaces, who can upload documents and whether an agent can use network or code tools. Review the selected model provider and where prompts and retrieved content travel. A local UI does not guarantee a local model.

For owned instances, test unauthenticated access, access with an ordinary user, access with an administrator and API access after key rotation. Check that old documents and cached embeddings do not appear in a new user's workspace. If the instance was intentionally single-user, keep it on a private network with an explicit access layer.

The scanner gives a candidate population. The deployment mode and data visibility determine the risk.

References

FTPS can protect the login and still leave the file transfer exposed

andreagomez — Sat, 07 Nov 2026 05:21:10 +0000

FTPS can protect the login and still leave the file transfer exposed

FTP with TLS is usually described as a secure version of FTP, but the control channel and the data channel are separate. RFC 4217 defines extensions that let a client negotiate TLS with AUTH TLS, set protection with PBSZ and PROT, and protect subsequent commands and transfers. A service that upgrades the login but leaves the data connection in cleartext has not secured the file contents.

Use explicit TLS with verified certificates

Explicit FTPS starts with a normal control connection and then requests TLS. That makes the greeting and capability negotiation visible before the protected session begins, which is not the same as an end-to-end encrypted protocol. The client should verify the server certificate and hostname instead of accepting any certificate presented on the FTP port.

Require protected data connections for file contents. Review whether PROT P is mandatory and whether the server falls back to clear data for older clients. Disable commands that return the control connection to cleartext unless there is a specific, temporary migration need. Implicit FTPS is a vendor extension rather than the RFC 4217 model, so document it as an exception and test it with the same certificate policy.

Constrain the session

Restrict passive data ports to a documented range and firewall that range independently of the control port. If the server advertises an address that clients cannot reach, NAT and firewall changes may force insecure workarounds. Keep user home directories isolated and test path traversal, symlink handling and rename behavior with a low-privilege account.

Use separate service accounts for integrations and humans. Rotate credentials after an application change, and review scripts that store passwords in command lines or plaintext configuration. Certificate renewal needs its own owner. An expired certificate can cause clients to retry with verification disabled, which turns a maintenance error into a policy failure.

Identify the service by behavior

Port 21 is a hint, not proof that FTPS is enforced. Inspect the advertised AUTH TLS support, the certificate chain, the protected data-channel requirement and the final transfer mode. Inventory hosts that still accept cleartext FTP and distinguish them from servers that merely listen on a legacy port.

Monitor failed TLS handshakes, repeated certificate errors, anonymous login attempts and unusually large transfers. After a suspected data-channel exposure, rotate the affected credentials, determine which files were transferred, inspect server logs and notify the data owner. Re-enabling TLS without reviewing client fallback can leave the same cleartext path available.

References

Bitwarden collection management changes what an administrator can read

andreagomez — Sat, 07 Nov 2026 02:04:54 +0000

Bitwarden collection management changes what an administrator can read

Bitwarden organizations share vault items through collections. A collection is not just a folder label. It is the boundary that determines which members can see or manage the items assigned to it. Owners and administrators have organization-level duties, but the collection-management setting controls whether their role automatically grants access to every collection.

Bitwarden's documentation describes four collection-management options and explains that the choice affects owner and admin access. One option can give those roles automatic management of all collections and items. Another requires an owner or admin to be granted access explicitly. The difference matters during incident response because an administrator who can manage users may not be able to read a protected collection.

Measurement evidence

On 2026-11-07 UTC, page-one count-only ZoomEye probes with sub_type=all returned 173,965 matches for app="Bitwarden", 84,735 for title="Bitwarden" and 190,894 for http.body="Bitwarden". These observations show a large product footprint, not a count of exposed or weakly configured organizations. App matches can include client and server components, while body matches can include help pages and documentation.

Review the organization model

Inventory organizations, owners, administrators, groups, collections and external identity providers. For each collection, record its owner, membership source and whether admins receive automatic access. Test an owner, an administrator, a collection manager and a normal member. Confirm that a member cannot see a collection merely because the web client hides its name.

The three-step onboarding process described by Bitwarden is also a useful audit trail: invite, accept and confirm. Unconfirmed invitations and stale organization members should be reviewed. Groups can simplify scaling, but a broad group-to-collection association can produce the same access as individual grants.

Separate recovery from routine access

Owners and administrators may be able to export organization data depending on the collection option and product configuration. Treat that capability as a recovery control with its own logging and approval. Do not let a routine help desk role inherit it.

After an account compromise, revoke sessions, remove organization access, rotate the account password and review collection history and exports. Removing an administrator from the organization does not repair a collection that was intentionally shared with a broader group. Review both role and collection membership.

The useful security question is who can decrypt or export which collection under the deployed policy. A product count cannot answer that.

References

FreshRSS API passwords create a second access path

andreagomez — Fri, 06 Nov 2026 22:45:13 +0000

FreshRSS API passwords create a second access path

A FreshRSS user may log in to the web interface while native apps use a separate API password. The two paths can have different exposure and logging behavior. Treating the API password as a copy of the web password obscures that boundary.

FreshRSS documents API access for mobile and native clients through the Google Reader API and the Fever API [1]. The mobile access guide instructs administrators to enable API access and users to set an API password in their profile [2]. The project's access-control documentation also describes form authentication, HTTP authentication, and an uncontrolled state with no authentication [3]. The deployment must choose one of those models deliberately.

Observed inventory

On 2026-11-07, a ZoomEye count-only probe with title="FreshRSS", sub_type=all, page 1, and pagesize 1 returned 11,840 matches [4]. The app probe returned 9,530 and the body query 26,651. These fields can surface valid installations and product references, but they do not prove that API access is enabled or that a password is weak.

Inventory the two login paths

Review API enablement, per-user API passwords, OpenID Connect or HTTP authentication, and any anonymous mode. A shared deployment should not allow one user's feed list, labels, or credentials to influence another user's session. Test a user who is disabled in the web interface but still has an API password, and a password change that does not invalidate an existing client.

Protect feed credentials

FreshRSS stores feed endpoints and may hold credentials or tokens used to fetch private sources. Those values belong to the same trust boundary as the user's session. Restrict server egress to expected destinations, separate administrative access from user accounts, and avoid placing API passwords in URLs or public dashboards. If a feed URL contains a secret, rotate it when the feed is changed.

Harden the web boundary

Use TLS, a supported authentication mode, and a reverse proxy that does not bypass the API path. Review the documented web-server instructions for protecting the API separately from the main interface [3]. Back up user and feed metadata with encryption and test restoration. Monitor repeated authentication failures and unusual feed additions.

Validate before acting

A ZoomEye title query can identify a product page for an authorized inventory check. It cannot show whether the instance is a test server, whether anonymous access is enabled, or whether a user has an API password. Confirm ownership and use approved configuration access before drawing an exposure conclusion.

FreshRSS connects users to external feeds and stores their reading state. The separate API path deserves its own lifecycle and test coverage.

References

Tactical RMM agent onboarding and operator roles

andreagomez — Fri, 06 Nov 2026 19:21:10 +0000

Tactical RMM agent onboarding and operator roles

Tactical RMM is a remote monitoring and management platform. An installed agent can run scripts, collect system information and support remote control. That makes the RMM server a high-value operational control plane. An operator who can add an agent or run a script may be able to change many managed endpoints at once.

On 2026-11-07, a count-only query for app="Tactical RMM" matched 18,745 assets. The title query returned the same 18,745 and a body keyword returned 18,447. The agreement suggests a coherent application fingerprint, but the count still represents matched public assets, not confirmed vulnerable installations or exposed administration panels.

Control enrollment

Tactical RMM documentation describes several agent installation methods, including generated executables and scripts. Each method should map to a controlled enrollment process. Protect the installation token or generated package, limit its lifetime and record which client, site or policy it is intended to join.

Do not allow arbitrary users to download installers or reuse an old package across unrelated tenants. A deployment package can carry site context and installation choices. Treat it as a credential-bearing artifact even when it does not contain a password in plain text.

Scope the operator role

The permission manager defines what a technician can see and do. Review script execution, file browser, screen control, software installation and agent management as separate capabilities. A user who can read dashboards may not need the ability to run commands as a system account.

Scripts have different execution contexts. Tactical documentation notes that some commands run through the agent's native security context, while a RunAsUser option changes the account. Define which users may invoke each context and require review for scripts that run with elevated privileges.

Treat API keys as user authority

An API key is associated with a user, and its permissions reflect that user's role. Create service keys for dedicated integration accounts rather than borrowing an administrator's identity. Restrict source networks where possible, rotate keys and disable them when the integration is retired.

Review access to MeshCentral and other remote-control components separately. A product installation can combine several management surfaces with different authentication and permission models. An exposed endpoint may be an API, a dashboard, a remote-control service or a reverse-proxy route.

Validate the control plane

Use a test client and site to verify which role can install an agent, run a read-only script and open a file browser. Confirm that denied actions are logged. Remove a test role and check that active API keys and sessions lose the expected access.

Monitor new agents, changed sites, script execution and permission changes. An unexpected agent is a potential unmanaged endpoint. An unexpected script is a potential configuration change. Both deserve investigation before the next scheduled maintenance window.

Measurement limit

The public fingerprint helps identify the scale of visible Tactical RMM deployments. It cannot establish whether the login page, API or remote-control route is reachable from the Internet. Verify the service with the owner and inspect authentication before treating the count as an exposure finding.

The operationally useful question is which identities can change the fleet and how those changes are audited. An RMM with narrow roles, controlled enrollment and independent logging is materially different from one where every technician has administrator access.

References

Tactical RMM. Permissions.
Tactical RMM. API access.
Tactical RMM. Agent installation.
ZoomEye. Count-only search.

Turning GhostAction into a repeatable external GitHub monitoring loop

andreagomez — Fri, 06 Nov 2026 16:01:04 +0000

Turning GhostAction into a repeatable external GitHub monitoring loop

GhostAction returned with a larger workflow injection wave in October 2026. GitGuardian reported more than 30,000 targeted repositories, about 1,900 compromised GitHub accounts, and 3,174 secret attempts. The figure most likely to change a security program is not any single total. It is the speed of the campaign and the number of trusted automation paths a single maintainer identity can reach.

An external monitoring loop can help a team maintain context around the GitHub platform and its public services. It cannot replace repository, workflow, and identity monitoring. The loop should make that boundary explicit so that a change in a public observation is investigated without being confused with proof of compromise.

A baseline for the public platform

On November 6, 2026, ZoomEye returned 101 matches for domain="github.com" and 54 matches for the same domain with port 443. The observations were collected at 15:46 UTC. A product-fingerprint query for app="GitHub Enterprise" returned 12,520 matches at 15:47 UTC.

These values describe different public surfaces. The domain query is broad platform context. The port subset is a smaller view of web exposure. The product fingerprint describes assets that matched a named application field, not every enterprise deployment and not the repositories involved in GhostAction.

Store each observation with the exact query, timestamp, scope, result ID, and a plain-language unit. If the count changes, the first question is whether the query or platform changed. Do not assign an incident state from a count alone.

Pair the external loop with internal controls

A useful weekly review can combine four tracks:

External: GitHub domain and public asset observations from a fixed query.
Repository: workflow-file changes, direct commits to protected branches, and new third-party actions.
Identity: maintainer access changes, personal access token creation, app installations, and high-impact account actions.
Runtime: workflow executions that access secrets and make unexpected outbound connections.

The external track is the smallest part, but it gives the team a stable way to document the public platform surface. The repository and identity tracks answer the questions that determine containment.

Make the alert criteria specific

Avoid an alert that says "GitHub changed." A more useful rule combines a new or changed external observation with a change in ownership or service behavior. For internal records, alert on a maintainer account committing a workflow directly to a default branch across multiple repositories, a workflow file appearing under an unusual name, a sudden manual dispatch, or a runner connecting to an unapproved destination.

The reviewed research provides useful indicators: file names that resemble security improvements, rapid workflow pushes across repositories, history-scanning behavior, and outbound HTTP to an unusual IP. Use these as review leads. Do not treat every occurrence of a string as a confirmed compromise.

Preserve the evidence chain

For each finding, record the source and the time. A ZoomEye observation should retain the exact query and result identifier. A GitHub audit event should retain the account, token, repository, action, and time. A network log should retain the flow's source, destination, and bytes transferred. These records answer different questions and should not be collapsed into a single "affected" count.

The chain is also useful for learning. If a workflow was blocked before execution, the team can test whether the blocking control works as expected. If a run reached an external host, the team can trace the credential's downstream use. The distinction supports a more accurate post-incident review.

Test the controls on a schedule

Run tabletop checks against the current repository inventory. Can a new workflow run without review? Which token can edit a protected branch? Which runner can reach the internet? Can a maintainer read repository secrets? Are old credentials still valid? A control that exists in policy but has no tested evidence is only a plan.

The same review should test the external baseline. Confirm that a query returns a usable count, that the scope is documented, and that an analyst can explain what the result does not show. This is a small but repeatable way to keep the monitoring loop honest.

Close with decisions, not a dashboard

Each review should end with named decisions: disable an unused token, add a workflow review requirement, convert a static cloud credential to OIDC, reduce a token's scope, or open a validation task for an unexplained connection. The public asset count is useful only when it supports one of those decisions or documents a change that needs investigation.

GhostAction is a reminder that an external search engine sees a narrow slice of the supply chain. The rest sits in account permissions, workflow code, secret access, runner behavior, and provider logs. A monitoring program should connect those views while keeping their evidence boundaries intact.

References

Redfish Sessions Need Their Own Privilege Review

andreagomez — Fri, 06 Nov 2026 12:41:47 +0000

Redfish Sessions Need Their Own Privilege Review

Redfish exposes server and infrastructure management through a small HTTP API. A session token can reach power controls, virtual media, firmware inventory, event logs, and account management when the associated role allows it. The transport is regular HTTPS, so teams sometimes put it behind existing network controls and forget that the API has a separate identity model, session lifecycle, and privilege mapping.

Session creation is an authentication event

The Redfish specification describes session login through an HTTP POST to the session collection. A successful response creates a Session resource and returns a session identifier. Clients then use that identity for subsequent requests. Basic authentication may also be supported, depending on the service, but it sends credentials with every request and should not become the default for automation when sessions are available.

Sessions have a location, an account association, and a lifetime defined by the service. An administrator should be able to list active sessions, identify the associated account, and delete a session after a suspected token theft. A service that hides session inventory or never expires automation sessions is harder to contain.

Roles and privileges are separate from the token

The token proves that a session was created. The service still evaluates each operation against Redfish privileges and the role assigned to the account. The specification defines an operation-to-privilege mapping and supports compound privilege requirements, including AND and OR relationships.

A user with login capability is not automatically authorized for every resource. Review the effective role against the API operations an integration actually uses. A monitoring collector may need read access to health and inventory but no Login privilege for account management, no ConfigureManager, and no virtual media control.

Inventory the BMC boundary

Start with the management address, service account owner, authentication method, session timeout, certificate trust, and network path. Include out-of-band management switches, VPNs, jump hosts, and monitoring systems that can reach the baseboard management controller.

Look for shared accounts used by multiple tools. Shared sessions make audit reconstruction difficult and prevent targeted revocation. Prefer one account per automation function where the service supports it. Store credentials in a secret manager, not in scripts or repository variables.

Test the lifecycle

Create a test session, confirm its expiry, delete it, and then verify that the token fails. Test account disablement while a session remains open. Check whether a role change takes effect for existing sessions or only after reauthentication. Review the event log for login, logout, session deletion, account changes, and privileged actions such as reset or virtual media insertion.

Limit the management plane to trusted networks and require TLS certificate validation on clients. Do not disable certificate validation to make an inventory job work. If a certificate is wrong, fix the certificate or remove the client from the path.

Respond to a suspected token leak

Treat a Redfish session token as a live administrative credential. Delete the session, disable or rotate the backing account if necessary, review recent operations, and compare the service event log with change records. Do not stop after deleting the token from the client configuration; the service may still consider it valid until expiry or explicit deletion.

Redfish makes infrastructure automation practical because it exposes a consistent management API. That consistency also makes privilege drift easy to scale. Regular review of accounts, roles, sessions, certificates, and network reachability is more useful than treating the management endpoint as an opaque appliance.

References

Dolibarr API Tokens Inherit the User Permission Model

andreagomez — Fri, 06 Nov 2026 09:00:36 +0000

Dolibarr API Tokens Inherit the User Permission Model

Dolibarr exposes ERP and CRM data through a REST API. An API token is associated with a user, and that user's permissions determine which modules and records the request can reach. Treating the token as a generic application secret misses the fact that each integration may be operating with a named person's rights.

The token points to a user

Dolibarr's REST API documentation instructs operators to paste the API token for the user who will call the service. The permissions documentation describes module permissions stored in user and group relationships. The effective API authority is therefore the result of the user, the groups, the module rights, and the object-level behavior of the endpoint.

Create a dedicated integration user for each application or business function. Do not issue a token for a general administrator because setup is easier. Grant only the permissions the endpoint sequence needs, then test denied actions as well as successful ones.

Review groups and defaults

Group membership can make an individual token broader than its owner understands. Review inherited permissions, default permissions assigned to new users, and any group that was created for a temporary project.

Dolibarr's security settings documentation notes that default permissions apply to newly created users and do not retroactively change existing users. That makes defaults an onboarding control, not a repair mechanism. Existing integration users need explicit review.

What the ZoomEye observation shows

This measurement used count-only queries with sub_type=all, page 1, and page size 1. app="Dolibarr" returned 812, title="Dolibarr" returned 4,238, and http.body="Dolibarr" returned 1,012,186.

The body count is far too broad for an installed-base claim. It can include documentation, integrations, and unrelated references. The application fingerprint is smaller and more specific, while the title count captures pages that expose the product name in HTML.

Use these counts to prioritize a comparison with DNS, certificate, and cloud inventory. Do not attempt to authenticate or enumerate records on an unknown Dolibarr instance.

API-specific checks

Record the endpoint family, required module permission, token owner, token storage, and last use. Test list, read, create, update, and delete operations with the integration user. Confirm that a denied module returns an authorization failure rather than an empty result that the application might interpret as success.

Review webhook and outbound integration credentials separately. A compromised API token may allow the attacker to read business records, but a webhook secret may let them forge events into another system.

Rotation and offboarding

When a staff member leaves, do not only disable the human account. Find every API token issued to that account and determine whether an integration depends on it. Move the integration to a dedicated user before revoking the token.

Rotate tokens on a schedule and after suspected exposure. Update the secret store first, verify the new token, then revoke the old one. Check logs for both users during the transition.

A Dolibarr token is a delegated user identity. The useful inventory is not a list of strings; it is a list of users, groups, permissions, and business records that each string can reach.

References

Android Network Security Config: Trust Anchors Are a Policy Decision

andreagomez — Fri, 06 Nov 2026 05:40:40 +0000

Android Network Security Config: Trust Anchors Are a Policy Decision

Android's Network Security Configuration gives an app a declarative place to define how TLS connections are trusted. The file can restrict CAs, add an internal trust anchor, disable cleartext traffic, require certificate transparency, or pin certificates. Those choices are security policy, and they need review in the same way as authentication code.

Start with the trust anchor

Android documents that, by default, secure connections use the pre-installed system CAs. Apps targeting Android 6.0 or lower also trust user-added CAs by default. Modern apps normally do not trust the user store unless a configuration says they do.

A custom trust anchor can be appropriate for a private service. It also narrows the trust decision to a certificate or CA that the team must operate. The Android documentation notes that certificate transparency verification is not performed for connections that use custom trust anchors. That does not make custom CAs insecure. It means the team must compensate with certificate lifecycle controls, monitoring, and a clear reason for the exception.

<network-security-config>
  <base-config cleartextTrafficPermitted="false">
    <trust-anchors>
      <certificates src="system" />
    </trust-anchors>
  </base-config>
  <domain-config>
    <domain includeSubdomains="true">internal.example.invalid</domain>
    <trust-anchors>
      <certificates src="@raw/internal_ca" />
    </trust-anchors>
  </domain-config>
</network-security-config>

The hostname and CA name are illustrative. The trust should be scoped to the domains that actually need it.

Keep debug overrides out of release

The debug-overrides element lets an app trust development CAs only when android:debuggable is true. That is a safer testing workflow than shipping a broad user CA trust in the production configuration. Verify the merged manifest and the packaged XML for release variants, and confirm that the release build is not debuggable.

Pin cautiously. A certificate pin that cannot be rotated can turn a routine certificate change into an outage. If pinning is necessary, define backup pins, an overlap period, and a mechanism to observe client versions before removing the old pin. Review the pinned hostname and the exact certificate or public key.

Test the policy, not just the XML

Run the release app against a valid internal host, an expired certificate, an unexpected public certificate, a user-installed test CA, and a cleartext endpoint. Record which connections succeed. Test debug and release separately because the effective policy can differ.

Check third-party SDK network stacks. Some may use their own trust configuration or bypass the app's expectations. Include the network security config in code review when a dependency adds a domain. A new domain without a policy can be as important as a changed certificate.

The configuration file is small, but it defines the certificate authorities and HTTP conditions the app will accept. Treat each exception as a documented operational commitment with an owner and a removal plan.

References

Android Developers: Network security configuration

Komga: API Keys and Library Restrictions Need to Be Reviewed Together

andreagomez — Fri, 06 Nov 2026 02:20:54 +0000

Komga: API Keys and Library Restrictions Need to Be Reviewed Together

Komga is a self-hosted media server, but its security surface follows the same pattern as many internal applications: users can have roles, clients can authenticate with API keys, and administrators can restrict which libraries a user sees. The effective access is the intersection of those controls, not the login method alone.

What the external measurement shows

On 2026-11-06 08:46:26 +08:00, ZoomEye count-only queries used sub_type=all, page 1, and pagesize 1. app="Komga" returned 1, title="Komga" returned 14,198, and http.body="Komga" returned 96,597. The title count is much larger than the application fingerprint. The body result is broad and should not be treated as deployment evidence without inspecting the matching records and attribution.

Authentication and user roles

Komga's API documentation says most endpoints require authentication. It supports HTTP Basic authentication and an API key in the X-API-Key header. Session cookies are created for credential-based login, while API-key authentication does not create a session. Admin endpoints for listing, creating, updating, and deleting users require the administrator role.

The user guide defines page streaming and file download as separate roles. An administrator can limit a user to specific shared libraries. The default is unrestricted access to all libraries, so a user account created for one collection needs an explicit review of its restrictions.

Review the effective grant

For each account, record its role, allowed libraries, content restrictions, API keys, last authentication activity, and owner. Check whether an API key belongs to an administrator, a delegated reader, or an integration. Because API keys authenticate the request directly, pair a key with a narrow user and the correct library restrictions rather than reusing an administrator for every client.

Test by logging in as a restricted user and requesting metadata, page content, and file downloads outside the allowed library. Repeat through an API key. A successful login is not enough evidence if the user can still enumerate another library or read a file through a different endpoint.

Operational response

Revoke unused keys and delete or restrict stale users. Review the reverse proxy and TLS configuration, then confirm that unauthenticated requests cannot reach administrative or file-download endpoints. Retain authentication activity long enough to support an investigation.

Use the external count to find candidate instances and verify ownership through internal records. The count does not reveal a Komga user's role or library scope. Those facts come from the controlled deployment and its audit evidence.