DEV Community: andreagomez

Vikunja's 540 application matches and 1,705 titles point to shares and token scope

andreagomez — Mon, 02 Nov 2026 08:02:14 +0000

Vikunja's 540 application matches and 1,705 titles point to shares and token scope

Vikunja is a self-hosted task and project manager. It can hold project plans, attachments, comments, and integrations that move data to other services. An exposed login page is only the first object in a useful review. The project sharing model and API token scope determine what an authenticated or link-based visitor can reach.

A ZoomEye SDK count-only query on November 2, 2026 returned 540 matches for app="Vikunja" and 1,705 for title="Vikunja". The queries used sub_type=all, page 1, and a page size of 1. The application fingerprint is more specific than the title, while the title result suggests that a title-only inventory would miss or overcount deployments.

Vikunja supports sharing with users, teams, and link shares. The documentation describes Read, Read & Write, and Admin permission levels. Link shares can let someone use a project without an account. Permissions can also be inherited through parent projects. API tokens are created in settings and carry permission choices for operations such as project management, tasks, comments, and webhooks.

Those features create several review paths:

Inventory projects with public or link shares and confirm the intended permission level.
Check password-protected links, expiration behavior where configured, and the owner of each share.
Review parent and sub-project inheritance rather than inspecting a child project in isolation.
Enumerate API tokens by owner, permission set, last use, and expiry.
Check webhooks that send project events to external endpoints and the signing or authentication they require.
Confirm that deleted users, teams, and shares no longer retain effective access.

An external count cannot distinguish a private task list from a project containing operational secrets. It also cannot show whether a link share has a weak or absent password. The count is useful for finding internet-facing instances, but the risk decision belongs to the project and token inventory.

Test the permission model with two accounts. Give one account read access through a team and another through a direct share, then verify the maximum permission the API reports. Try to use a task-level token on a project-management endpoint. A token should fail outside its declared scope even when the user can perform the operation in the web interface.

Vikunja's sharing design is practical for collaboration. The security team should treat link sharing, inherited permissions, and broad API tokens as separate authorization surfaces rather than assuming the login screen represents the whole boundary.

Query evidence

app="Vikunja" returned 540 matches. title="Vikunja" returned 1,705. Both queries used sub_type=all, page 1, and a page size of 1.

References

Measuring CVE-2026-105483 exposure without overstating it

andreagomez — Mon, 02 Nov 2026 04:42:08 +0000

Measuring CVE-2026-105483 exposure without overstating it

ZoomEye can show how widely a product fingerprint appears, but it cannot see the version, configuration, and certificate policy inside every deployment. CVE-2026-105483 makes that boundary important. The Node.js bug affected 24.x and 26.x before 24.22.1 and 26.12.1. During TLS verification, a fullwidth-digit IPv4 host could be treated as a DNS name, allowing a trusted certificate with a matching DNS SAN to authenticate an IP endpoint without an IP SAN.

Node.js rates the vulnerability High. The GitHub advisory lists CVSS v3.0 7.4 and CWE-295. An exposure measurement is useful for understanding the technology population and planning review, not for labeling every match as a victim.

What the query measured

The selected Search Dork was app="Node.js". ZoomEye returned 5,539,674 matches at 04:17 +08:00 on November 2, 2026. The CVE Filter vul.cve="CVE-2026-105483" returned zero. Under the selected-query rule, Exposure is the larger count, so the recorded value is 5,539,674.

The visible unit is a Node.js application fingerprint. It is not a count of processes running a vulnerable release, endpoints that accept fullwidth-digit hosts, or environments whose trust store can issue a suitable certificate. Those facts require different evidence.

Why the CVE filter returned zero

Zero CVE-indexed results does not mean zero vulnerable systems. ZoomEye's CVE field depends on indexed vulnerability evidence. A product fingerprint may not include the runtime version or certificate configuration needed to classify the CVE. The correct conclusion is that the observed index had no assets mapped to vul.cve="CVE-2026-105483" at the query time, not that every Node.js deployment was patched.

AutoPR's Exposure rule compares the selected successful queries and uses the greater count. The product query passes the threshold, while the Filter shows the narrower CVE-index view. Both facts can be displayed together without pretending they measure the same population.

Questions for the owner of a match

An operator reviewing a ZoomEye result should ask:

Is this an application server, a build service, an API gateway, or a device interface?
What Node.js release does the deployed process report?
Does the service accept destinations from tenants, integrations, or administrators?
Does it require an IP SAN for IP endpoints?
Which trust anchors and internal CAs can issue the relevant certificate?
What sensitive request is carried after the TLS check?

The first two questions narrow the technology. The next two determine whether the vulnerable identity path is reachable. The last two estimate consequence and practical attacker conditions.

Combine external and internal evidence

External indexing is good for discovering a broad population. Internal inventory should map application owners, runtime versions, build artifacts, and network exposure. A service can be publicly visible but use only fixed, approved DNS destinations. Another service can be private but accept an attacker-controlled callback and send a privileged token.

The private service may deserve earlier review because its business path combines destination influence, broad trust, and sensitive authority. Exposure counts help with scale and context, while threat modeling decides order.

Measurement discipline

Record the exact query, scope, time, and semantic unit. Preserve the runtime version evidence separately from the ZoomEye record. Do not write "5,539,674 vulnerable hosts" when the query measured product fingerprints. Do not add the Search and Filter counts.

If a service owner later confirms a vulnerable release and a reachable path, that becomes internal incident or remediation evidence. It does not retroactively change the meaning of the broad product query. Accurate labels let analysts compare runs without inflating a count.

Operational use

Use the fingerprint population to find teams that need an inventory request, not as a substitute for the request. Include build-system Node.js installations, command-line tools, agents, and packaged applications in the inventory because internet-facing web services are not the only relevant runtime class.

For each confirmed affected deployment, upgrade to 24.22.1, 26.12.1, or later. Rebuild images and packaged executables, verify the runtime after deployment, and add the certificate identity regression test to the release gate. For user-controlled destinations, require canonical DNS names or canonical IP literals and require the appropriate SAN class.

Reporting

A defensible report has two layers. The external layer says that a product query found 5,539,674 Node.js matches and that the CVE filter found zero. The internal layer names the systems confirmed to run affected versions, the clients with reachable trust decisions, the patch status, and the remaining risk.

Keeping those layers separate avoids a common failure in vulnerability management: treating a large public count as incident evidence or treating a zero CVE count as proof of safety. CVE-2026-105483 requires runtime and identity-policy evidence, both of which sit behind the fingerprint.

References

Elasticsearch API keys inherit an identity as well as a privilege list

andreagomez — Mon, 02 Nov 2026 01:20:49 +0000

Elasticsearch API keys inherit an identity as well as a privilege list

An Elasticsearch API key is more than a bearer credential with index names attached. It represents a principal and a set of role descriptors, and its effective authority depends on the user who created or granted it. That makes key lifecycle, owner auditing, and document-level restrictions part of the same authorization review.

The API key service can create user API keys and cross-cluster API keys. The request can include role descriptors for indices and cluster privileges, expiration, and metadata. The key should be limited to the APIs and resources it needs. A key with a broad role because it was created by a highly privileged user can expose data that the service using the key was never meant to read.

Review the owner and the descriptors

Start with the creating user or service account. Record its roles and the reason it is allowed to grant the requested privileges. The key's role descriptors define its intended scope, but the policy should also account for the owner's authority. A key that appears limited can still be risky if its owner holds broad cluster privileges and can approve or create another key.

Use distinct keys for scheduled jobs, dashboards, ingestion, and administrative automation. Do not share one key across teams. Put purpose and owner in metadata so that the key can be found during an incident. Set an expiration for temporary automation and reissue the key after the task. Keep long-lived keys to an absolute minimum and put them in a secret manager rather than a source-controlled configuration file.

A key can be invalidated independently. Build a response procedure that identifies the credential, revokes it, rotates dependent jobs, and checks for use after revocation. The audit trail should include key creation, privilege changes, owner changes, and invalidation. If a key is embedded in a container image, deleting the key from the current environment does not remove it from old images or caches.

Apply document and field restrictions deliberately

Document-level security and field-level security restrict which documents and fields a role can see. They are useful when a shared index contains multiple tenants or when a support role should see case metadata but not personal data. The restrictions interact with multiple roles. A user or key with another role may receive broader access, so evaluate the combined result rather than one role in isolation.

Test the effective query result with the key itself. A search that returns the expected tenant does not prove that an aggregation, field, alias, or cross-cluster request enforces the same restriction. Check terms aggregations, wildcard queries, scroll or point-in-time access where supported, and error messages that could reveal whether a restricted document exists.

Field-level restrictions depend on a query model that applies to all relevant APIs. An index operation, update, bulk request, or scripted query may have different privilege requirements. A key intended only for search should not hold index-management or scripting privileges. Separate data ingestion from interactive search so a compromised dashboard key cannot rewrite the corpus.

Make key issuance observable

Centralize approval for keys that can read regulated data or change security settings. Store the business purpose, owner, expiration, and expected source network. Alert when a key with broad privileges is created outside the approved workflow. Alert on use from a new service, region, or user agent when the logging pipeline can capture those fields without exposing the key.

Do not log the API key value. Authentication logs should use a key ID or metadata label. If a request contains a key in a URL or query string, fix the client so the credential travels in the header and does not enter proxy logs. Review error responses and dashboards for accidental token exposure.

Build a rotation test. Create a short-lived key, use it for the intended API, then invalidate it and confirm that the next request fails. Revoke the owner's access and verify whether existing keys continue to work according to the product's documented behavior and the deployment's policy. Test a tenant query with both a narrow key and a broader administrative key to show where the boundary really sits.

Elasticsearch API keys are compact, which makes them easy to distribute and easy to forget. Treat each key as a named principal with an owner, scope, expiry, and review date. The privilege list matters, and so does the human or service identity that stands behind it.

References

Checkmk exposure includes agent registration and monitoring trust

andreagomez — Sun, 01 Nov 2026 22:02:08 +0000

Checkmk exposure includes agent registration and monitoring trust

Checkmk monitors hosts, services, networks, and distributed sites. The public web interface is only one part of the trust model. Agents register with a site, distributed monitoring connects central and remote sites, and internal protocols exchange monitoring data. An inventory of Checkmk deployments should include those relationships.

A count-only ZoomEye query on 2026-11-02 returned 2,373 assets for title="Checkmk". The query used sub_type=all, page 1, and page size 1. A title match may include documentation, custom portals, or stale deployments. The count describes matching assets, not confirmed vulnerable instances.

The ZoomEye query provides a population for an ownership review. Match candidates to DNS, certificates, and known monitoring records before testing.

Make registration a controlled identity

Checkmk's monitoring-agent documentation describes registration between the Agent Controller and the site's Agent Receiver. Registration establishes a trust relationship, and later communication uses TLS. Registration is therefore an identity-provisioning action, not a routine health check.

Review which accounts or automation can register agents. Checkmk documents a registration role for automated host creation and TLS registration. Keep that role separate from general monitoring administration. Log registration attempts, successful enrollments, and certificate changes. Remove an agent identity when the host is retired.

Use the certificate overview to inspect site and remote-site certificates. The documentation describes certificates for distributed monitoring and mutual TLS. Record certificate fingerprints, validity, and assigned sites. A self-signed or manually copied certificate can be valid for a lab but needs an explicit trust decision in production.

Protect the distributed monitoring links

Distributed monitoring connects a central site with remote sites. The documentation recommends TLS for encrypted synchronization and notes that Livestatus is not intrinsically secure and should be kept on a secure network or VPN. A public web interface may sit beside an internal management path that must not be exposed.

Review firewall rules between sites. Permit only the documented ports and addresses, and prefer TLS. Do not expose the remote site's management API directly to the internet. If a site is in a different network zone, place the connection behind a controlled VPN or private link and monitor certificate failures.

Separate central and remote administrative roles. A remote-site operator should not automatically become a central-site administrator. Review LDAP or Active Directory mappings, if used, and test the group synchronization result. A directory group that grants access to every site should have a clear owner.

Inventory the public surface

For each candidate host, capture the hostname, certificate, address, product evidence, first-seen time, and organization. Determine whether the endpoint is a production site, a demo, or a documentation page. Check TLS and authentication settings through authorized observation. Do not attempt default credentials or unauthorized changes.

Compare public DNS and certificate names with the configured site URL. Check for old monitoring hosts, agent download endpoints, and remote-site names that were not retired. A host that no longer appears in the central inventory can still hold monitoring data or credentials.

Review access to the monitoring data itself. Metrics and inventory can reveal hostnames, software versions, network topology, and service ownership. Restrict dashboards and API access by role. Use an audit trail for configuration changes and logins. Alert on new administrator accounts, certificate changes, and registration bursts.

Test containment

Disable a registered agent and verify that it cannot continue sending accepted data. Remove a remote-site certificate and confirm that the central site rejects the connection. Test an unauthorized registration attempt and inspect whether the failure is logged with enough context to identify the source.

Checkmk gives an organization a detailed view of its infrastructure. That makes the monitoring platform a sensitive system in its own right. Treat agent registration, distributed-site trust, web access, and internal monitoring protocols as one security boundary. The ZoomEye count only identifies candidates; the internal certificate and role inventory determines what the trust relationships actually mean.

References

Faveo answers 1 app fingerprint and 122 title matches, and its API defaults need verification

andreagomez — Sun, 01 Nov 2026 18:41:03 +0000

Faveo answers 1 app fingerprint and 122 title matches, and its API defaults need verification

A help desk can be discovered through its public support page while its administrative and API surfaces remain hidden. Faveo's documentation covers tickets, agents, teams, departments, roles, webhooks, and an external API. A count-only inventory can find candidate deployments, but the API configuration determines whether a found page becomes a meaningful integration boundary.

The ZoomEye observations used sub_type=all, page 1, and pagesize 1. On 2026-11-02, app="Faveo" returned 1 and title="Faveo" returned 122. Both probes succeeded. The app value is too small to treat as a population estimate. The title count is name-based discovery, not proof of exposed API access or a vulnerable version.

The two counts describe different signals

One application fingerprint may indicate a narrow product signature. The 122 title matches include any page whose title contains the name. The difference is larger than a single order of magnitude, so the article uses the title set only for candidate discovery.

Faveo's developer documentation lists an external API with ticket operations, knowledgebase APIs, OAuth2 token handling, and an internal API. The GitHub API wiki documents that a fresh installation disables the API by default and provides an option to make an API key mandatory.

That wiki is old and should not be treated as the current product default without verification. It is still useful as a warning against assumption. A deployment may have enabled the API for integration and may not have required a key. The safe review question is not "Is the API present?" It is "Which authentication method is required for each endpoint in this version?"

Inventory agent authority

The project's agent documentation describes roles, departments, teams, and groups that grant permission. A ticket integration may need to create a ticket, reply, or read a limited queue. It does not automatically need access to user administration, teams, or all departments.

For each confirmed deployment, inventory API-enabled status, key requirement, OAuth clients, agents, administrators, teams, departments, and webhook destinations. Use a dedicated integration identity rather than a human administrator's credentials. Check whether a token can be used after the user is disabled.

Webhook events form an outbound data path as well. A ticket event can send subject, customer, or content metadata to another service. Confirm that webhook URLs use HTTPS, that destinations are owned, and that failed deliveries do not expose credentials in logs.

Confirm before testing

Reduce the 122 title candidates with safe HTTP metadata. A public support portal, login page, and product documentation page should be classified differently. Do not attempt to create a ticket, authenticate, or call an API without authorization.

When an authorized test is available, verify the API authentication matrix endpoint by endpoint. A global "API key required" setting may not describe every route. Check response codes for missing, malformed, and revoked credentials. Keep request logs free of ticket content and access tokens.

The single app match does not make the product uninteresting, and the 122 titles do not make every candidate an exposed API. The useful finding is the gap between product recognition and control-plane verification. Start with the exact version, API policy, agent roles, and ticket scope. The public support page tells you where the service is. The authorization state tells you what it can disclose.

References

Continuous exposure checks for Onamae-linked domains and certificates: what ZoomEye can answer

andreagomez — Sun, 01 Nov 2026 15:20:42 +0000

Continuous exposure checks for Onamae-linked domains and certificates: what ZoomEye can answer

The Onamae.com Desktop Cloud incident shows the value and the limit of an outside view. A security team can see public domains, services, certificates, and banners without accessing the provider's internal management plane. That view can support inventory and monitoring, but it cannot prove malware execution, customer impact, or the provider's root cause.

On November 1, 2026, AutoPR ran four successful all-asset ZoomEye queries for this event. The results were 0 observations for domain="onamae-desktop.com", 40 for domain="onamae.com", 96 for ssl="onamae.com", and 427 for ssl="onamae". The final query is the broadest because it matches the word Onamae in certificate text. None of the four is a victim count.

Define the question before the query

A domain query asks whether ZoomEye has an indexed observation associated with that domain. A certificate-text query asks whether indexed certificate material contains a string. Those questions are useful for finding public names that may belong in an asset inventory. They are not substitutes for authoritative DNS records, certificate transparency logs, provider asset records, or customer telemetry.

Write the decision the observation will support. If the goal is to verify that all provider-related public names are approved, compare the returned names and certificates with the organization's register. If the goal is to detect new public infrastructure, collect repeat observations and investigate changes. If the goal is to determine whether a customer server was affected, use provider and endpoint evidence instead.

Preserve the query record

Record the exact normalized dork, scope, query time, and count. Preserve the result ID if the command returns one. Keep the distinction between a successful zero and an error. A failed request is not evidence that a domain disappeared, and a missing result can reflect collection coverage, index timing, or a query that is too narrow.

The four observations are a single snapshot. They should not be plotted as a trend until repeated with the same dork, scope, and collection method. A count that rises from one run to the next may reflect indexing changes, brand use, unrelated certificates, or query behavior. The only defensible statement from the November 1 data is the count observed at that time.

Build an ownership workflow

Every returned asset or certificate needs an owner, purpose, expected lifetime, and response action. A certificate containing Onamae may belong to a provider service, a customer configuration, a third party using the brand, or an unrelated string match. Do not call it confirmed service ownership without another source.

The workflow should answer four questions. Is the name expected? Does the certificate belong to an approved service? Is the public exposure still necessary? Does the asset have an accountable team and monitoring path? A no to the first three should create a validation task, not an immediate destructive change.

Use the provider's official contact and status channels to validate critical assets. If the provider is in an active incident, document that the management portal may be unavailable and use a prearranged alternate path. External observation should support, not replace, the provider's evidence.

Watch the right changes

High-value changes include a new public domain, a changed certificate issuer or subject, a certificate that appears outside the approved inventory, and a provider-linked host that remains visible after an announced retirement. A security team can schedule checks and retain snapshots, but should not flood responders with raw count changes.

Set an alert only when a change has a decision attached. For example, a new certificate for a production domain may require owner validation, while a broad brand-text count change may be informational. Document the threshold and the person who reviews it.

Keep the evidence boundary visible

The Onamae incident's 26,739 figure describes servers that may be affected, not confirmed compromises. GMO has confirmed that customer information was taken outside the company and that attackers published claimed data, but the reviewed public reports do not identify the intrusion vector or a confirmed total. External observations cannot fill those gaps.

That is not a reason to ignore them. A disciplined outside-in program can catch forgotten names, unmanaged certificates, and public services that do not match the inventory. The value comes from linking the observation to an owner and a decision. A count without that context is just a number.

References

A Kubernetes admission match condition can silence the policy it was meant to enforce

andreagomez — Sun, 01 Nov 2026 12:01:22 +0000

A Kubernetes admission match condition can silence the policy it was meant to enforce

ValidatingAdmissionPolicy lets the Kubernetes API server evaluate Common Expression Language rules without calling an external webhook. A policy declares the validation expressions. A binding decides which requests use the policy and whether violations are denied, audited or merely warned. Match conditions narrow that scope further. They look like a convenience, but a false result skips the policy.

Kubernetes documentation is explicit that if any match condition evaluates to false, the API server skips the policy regardless of other errors. That behavior makes a careless expression a security configuration change. A condition intended to select namespaces with a particular label may silently exclude every namespace after a label migration. A condition that expects a parameter or request attribute may evaluate incorrectly during a version upgrade, and a policy that reports a warning does not necessarily block the object.

Treat the policy, binding and parameters as one unit. Review matchResources and matchConditions together. Confirm that the namespaces, resource kinds, operations and users selected are the ones the control owner intended. When the binding references a parameter resource, test what happens when the parameter is missing, changed or inaccessible. Also check who can update the policy, binding and parameter. A team that can edit a parameter may be able to turn a deny into an audit rule without touching the CEL expression.

Use audit and warning actions before enforcement, but do not let a clean audit report substitute for a negative test. Build requests that should be denied, requests that should be allowed, and requests just outside the policy's scope. Apply them with dry-run where supported and inspect the admission result. Then test the same cases after a cluster upgrade and after any change to labels, namespaces or parameter objects.

CEL expressions should fail closed when the request does not contain the fields needed to make a decision. Avoid expressions that accidentally compare an absent value to a permissive default. Keep messages specific enough to explain the rejected condition without echoing secrets. Bound expression cost and object size because admission runs in the API server and affects the control plane, not only the target workload.

The control plane needs an ownership model. An application team may own the content of a policy while the platform team owns the binding and the parameter resource. If both teams can change both layers, the separation is cosmetic. Store the intended scope in version control, review changes with the same process used for RBAC, and alert on policy or binding changes that disable a security control.

There is no universal expression that makes an admission policy safe. The useful pattern is explicit scope, tested deny cases, a named owner, and a response plan for parameter or label drift. A policy that exists in the cluster is not necessarily a policy that evaluated against the request that mattered.

References

InvenioRDM's small title count still carries a record-access decision

andreagomez — Sun, 01 Nov 2026 08:40:13 +0000

InvenioRDM's small title count still carries a record-access decision

InvenioRDM is a research data repository framework built for records, files and community workflows. A small internet count is not a reason to ignore it. Repositories often publish only the metadata needed for discovery while keeping files restricted, and a customized or reverse-proxied deployment may have no recognizable application fingerprint at all.

On 2026-10-31, a count-only ZoomEye query returned zero matches for app="InvenioRDM" and 87 for title="InvenioRDM". Both used sub_type=all, page 1 and page size 1. The title query ran at 23:44:38 UTC; the application query ran at 23:44:36 UTC. These values describe search results, not the number of active or vulnerable repositories. The zero application result is especially weak evidence for a framework that organizations often brand as their own repository.

The first control to inspect is record access. InvenioRDM supports private records and file-level restrictions. A record can be visible while its files are not, or a record can be restricted as a whole. Review the record's access settings, the file settings and the community or collection membership. A public landing page should not imply that every attachment is public.

The API exposes access links and record management operations. Test anonymous retrieval, an authenticated user without a role, a record owner and an administrator. Verify that a token cannot retrieve a file merely because the caller can see its metadata. Also check what happens when a record changes from private to public or the reverse. Cached search pages, OAI exports and file links may retain the old state after the primary record has changed.

Tokens need an owner and a purpose. A personal token used by a deposit script may have write access to records the script no longer manages. Scope the token, rotate it after staff changes, and record the last use. Do not place a token in a public repository or embed it in a browser application. The API should reject expired or revoked credentials without revealing whether a private record exists.

The narrow title count also affects the discovery workflow. Start from the exact match, verify the host and response, and look for the API and community identifiers. If the site is customized, search for a repository link, DOI resolver, OAI endpoint or a known community page. Then add the asset to the organization's own inventory rather than relying on another query tomorrow to find it again.

A repository review should compare the public catalog with the actual file store. Check whether temporary download links expire, whether anonymous users can enumerate recent deposits, and whether a deleted or unpublished record leaves a file reachable through an object-store URL. InvenioRDM can manage access, but the integrated storage and CDN configuration still need to honor the same policy.

For 87 title matches, a defensive team can sample only candidates it owns or is authorized to assess. The goal is not to probe every public repository. It is to confirm that a small, high-value research-data service has an explicit boundary and a way to prove it. A low count is an observation. The permission matrix is the security evidence.

References

A cached sudo timestamp is a policy decision with a lifetime

andreagomez — Sun, 01 Nov 2026 05:22:00 +0000

A cached sudo timestamp is a policy decision with a lifetime

Sudo authentication is often treated as a one-time event followed by a short period of convenience. The timestamp cache is more accurately a policy object. It decides whether a later invocation can inherit proof of an earlier authentication, which terminal or process it belongs to, and how long that proof survives.

The sudoers manual documents timestamp_type, timestamp_timeout, and the way time stamps are associated with the user, terminal, and process session. The default behavior and available types can vary by build and configuration. A review should inspect the effective configuration on the host rather than relying on a generic Linux default.

A global timestamp can be reused across sessions in ways that a tty or ppid policy would prevent. A long timeout increases the window after a user walks away. A negative timeout can be configured to avoid expiration, which may be intentional on a dedicated console but is a poor fit for a shared endpoint. The system clock and monotonic-clock behavior also affect how records are evaluated.

Session scope is not command authorization

The timestamp cache does not encode an approval for every future command. It records that authentication happened recently enough for sudo's policy to accept. The sudoers rule still decides which command and arguments the user may run. Treating the cache as a business approval can turn a permitted administrative command into an unintended privileged operation.

The cache also interacts with terminal multiplexing, remote sessions, and process parents. A record associated with a tty may outlive the user's visible session. A record associated with a parent process may be reused by a child process. Those are normal implementation details, not proof that a cached authentication is stale in every case. They are reasons to test the intended session boundary.

Inspect and verify

On each host class, run sudo -V to identify the build and supported timestamp options. Read the effective sudoers policy with visudo or a validated configuration dump, then record timestamp_type, timestamp_timeout, and any per-user overrides. Check whether the timestamp directory is cleared at boot and whether the host can access a reliable boot-time record.

Test with a non-administrative account in a lab. Authenticate once, open a second terminal, and verify which invocation asks for a password again. Let the timeout expire and repeat. Test a command that remains denied even after authentication. Do not use an operator's real privileges or a production emergency account as the test subject.

The result should match the operational expectation. If an administrative session can inherit authentication from a different terminal or a stale parent process, document why that scope is acceptable. If the answer is simply that the default is convenient, the timestamp policy needs an owner and a shorter period.

References

sudoers manual, timestamp behavior

Chibisafe exposure begins at upload policy, not the download link

andreagomez — Sun, 01 Nov 2026 02:01:19 +0000

Chibisafe exposure begins at upload policy, not the download link

Chibisafe is a self-hosted file upload service with user accounts, API keys, albums, public links, and an admin dashboard. Its external footprint can look like a single upload page. The security review has to ask who can upload, who can list or delete files, and whether a public link is the only path to an object.

The official API documentation separates ordinary user routes from admin routes for user and file management. The project documentation also describes API keys for integrations and public upload behavior controlled by administrators. Those controls belong in the same review as storage quotas and file retention.

A small title set with a specific API

A ZoomEye SDK query for title="Chibisafe" returned 55 matches on 2026-11-01 at sub_type=all, page 1, and pagesize 1. The app="Chibisafe" query returned 0. Fifty-five is a modest title count, not a statement that the instances are safe. The product may be installed behind a custom title, and a public upload form may not identify the software.

The count only establishes that the exact title was observed. It does not show whether anonymous uploads are enabled, whether file contents are scanned, or whether a public file can be enumerated by UUID. Those are configuration and application tests.

Map the file lifecycle

List the upload entry points. Include the browser, API key routes, chunked upload endpoints, and any reverse-proxy route that bypasses the application. Confirm which routes require an authenticated user and which are intentionally public. Check the admin routes that approve, delete, or quarantine files.

Review API-key scope and lifetime. A key issued for an automation tool should not be able to manage users or purge public files. Test a key against an admin route after removing its user's admin role. The denial should occur regardless of the client used.

Examine how public links are generated and revoked. A random identifier can make guessing difficult, but the link may still be copied into a chat, support ticket, or browser history. Hash the storage path and record the link's owner. Test deletion and retention jobs with a disposable file.

Storage location matters as well. A container volume, object store, and thumbnail cache may have different access rules. Verify that a file removed from the application is also unavailable through a direct storage URL or a leftover static route.

The title count is a starting measurement. The useful decision comes from the upload, API, admin, and storage boundaries around it.

References

Coturn exposure: an unauthenticated TURN server is a relay, not a discovery endpoint

andreagomez — Sat, 31 Oct 2026 22:40:27 +0000

Coturn exposure: an unauthenticated TURN server is a relay, not a discovery endpoint

Coturn is a STUN and TURN server that relays media for WebRTC and other NAT-traversal workloads. Its reachable ports are part of normal operation. Authentication determines whether an arbitrary client can use those ports to relay traffic.

On 2026-10-31 at 21:56 UTC, one count-only ZoomEye query returned 8,186 matches:

app="coturn" || title="coturn"

The query used sub_type=all, page 1, and page size 1. It does not establish that a matching service is anonymous, misconfigured, or using coturn rather than another TURN implementation. The count is an inventory clue.

Authentication is not enabled by implication

The coturn turnserver manual page documents -a/--lt-cred-mech for long-term credentials, -z/--no-auth for anonymous access, and the REST credential option. It states that no credential mechanism is used by default when no authentication-related option is set.

That makes the effective configuration the primary question. A deployment that needs authenticated relay should verify it is using long-term credentials or a supported shared-secret mechanism. The coturn README describes classic long-term credentials, the TURN REST API, and an experimental OAuth option.

Do not rely on a client's configuration alone. The server must reject an unauthenticated allocation attempt when authentication is required. Test the TURN protocol path as well as the TLS login page and HTTP status.

Protect the REST secret

The coturn configuration reference includes options for authentication, TLS, relay ranges, and monitoring. The turnserver manual describes a static authentication secret for the TURN REST API and derives credentials from a timestamp and user identifier.

Store the shared secret outside the web client. Rotate it with a coordinated update to the service that mints TURN credentials. Use a bounded credential lifetime and confirm that an expired credential fails. Do not publish the secret in a frontend bundle, a repository, or a support transcript.

Restrict the relay address range and exposed media ports to the deployment design. Review whether the metrics or telnet management listener is exposed with the TURN service. The coturn project README describes Prometheus metrics as a build dependency and the project as a TURN/STUN gateway, so a broad network rule can expose more than media.

Test with the actual protocol

Use a controlled coturn instance and a test credential:

Request an allocation without credentials when auth is required.
Request an allocation with a valid credential.
Try an expired REST credential.
Try a credential for an unexpected user or realm.
Verify the permitted relay address range.
Check the source network allowed to reach the TURN port.

Do not print passwords or the shared secret. Record the protocol, realm, source network, credential type, and result. Test both TCP and UDP where the deployment advertises both.

The 8,186 matches can help identify TURN infrastructure outside an asset inventory. They do not prove anonymous relay. The answer comes from the running configuration, credential test, and firewall review on the organization's own deployment.

Operational checks

Keep the TURN service patched and its configuration under change control. Alert on anonymous auth flags, new exposed listeners, shared-secret rotation, and a relay address range that is wider than intended. Test the authentication path after every configuration change and before publishing a new WebRTC service.

References

HomeBox title matches are an inventory lead, not proof of exposed inventory

andreagomez — Sat, 31 Oct 2026 19:20:18 +0000

HomeBox title matches are an inventory lead, not proof of exposed inventory

HomeBox stores an inventory of physical items, labels, locations, attachments, and the people who can access them. The web interface is useful for household management, but the API is the same information surface in a different form. A search result that contains the product name does not establish that item data is reachable.

HomeBox supports users, login sessions, password reset tokens, and API keys. Those are different credential lifetimes. A browser session may expire quickly while an API key remains valid for an integration. A password reset token has a different risk again because it can change the account state.

Measured observations

On 2026-11-01, app="HomeBox" returned 0 matches in the selected ZoomEye scope. The title query title="HomeBox" returned 7328. Both used page 1, page size 1, and sub_type=all.

The zero app result does not mean no HomeBox deployments exist. It means the selected application fingerprint did not return a match. The title query is broad and can include documentation, project pages, and unrelated sites. It should be used to find candidates, not to estimate a confirmed exposed population.

Inspect the application boundary

For a controlled deployment, record the public hostname, listener, TLS terminator, authentication method, registration setting, and API routes. Check whether the instance is intended for one household or multiple users. Review who can invite users, reset passwords, create API keys, and export data.

Test an unauthenticated request to the item list and to a static page. A login redirect for the browser route does not prove that every /api route requires a session. Use a test user and synthetic items for any authenticated check.

Inspect API keys for purpose and age. Keys that were created for a retired dashboard or barcode printer should be revoked. Do not expose a key in a QR code image, URL, or shared note. If the application supports static API keys in addition to session tokens, keep the two inventories separate.

Review attachments and exports

Inventory item attachments, photo storage, and export features. A public web route can be protected while direct object storage URLs remain public. Check the storage configuration and the hostnames used for uploaded files.

Export files deserve their own retention policy. A complete inventory export may include personal information, purchase records, or location descriptions. Restrict download links and remove old exports from shared directories.

Make the title count actionable

Use the title result to identify candidate deployments and collect owner evidence. Confirm the product, authentication state, and API boundary through an approved test. Then decide whether the instance should be on the public internet at all.

The count is a discovery observation. The HomeBox owner should supply the deployment and credential record, and the test should show both a rejected unauthenticated item request and a successful authorized request with synthetic data.