DEV Community: yutianle

OIDC token hashes need a flow and an algorithm, not a generic equality check

yutianle — Sun, 15 Nov 2026 11:42:20 +0000

OIDC token hashes need a flow and an algorithm, not a generic equality check

OpenID Connect binds tokens and authorization codes to an ID Token with hash claims. at_hash covers an access token in flows that return one from the authorization endpoint. c_hash covers an authorization code in hybrid flows. The claim is a base64url encoded, left-most half of a hash of the ASCII representation of the bound value. A verifier that treats the value as an arbitrary opaque string is not performing the check the specification describes.

The hash algorithm is tied to the JWS algorithm used to sign the ID Token. A verifier must first validate the signature and establish the key, then calculate the expected hash with the matching function. Do not accept an algorithm supplied only by the token's own header when that algorithm is outside the client's registered policy.

OpenID's Token Hash Algorithm Implementer's Guide adds a useful distinction for modern algorithms. EdDSA does not identify a single hash function by name. The implementation must determine the parameter set from the validated key, including the JWK crv value. The guide records SHA-512 for Ed25519 and SHAKE256 for the ML-DSA family, while noting that decisions for SLH-DSA remain open. A generic hash selector keyed only by alg will be wrong or incomplete.

Check the flow that produced the ID Token

An authorization response that includes an access token or authorization code is a different event from a token-endpoint response. In the relevant flows, c_hash and at_hash let the client detect substitution during the front-channel exchange. The claim is not a replacement for PKCE, state validation, nonce validation, issuer validation, or audience validation.

Read the claim in context. An optional claim that is present should be checked. A required claim that is missing should be a failure. A claim from a different flow should not be accepted just because its field name is familiar.

The comparison should be constant time and should use validated bytes, not a browser-normalized string. Handle padding and base64url exactly as specified. Reject a digest with the wrong length instead of comparing a prefix. Keep a test vector for each registered JWS algorithm the client accepts.

Operate the algorithm policy

Record the JWS algorithm, key type, hash function, and flow in logs. Do not record the code, access token, or ID Token. Alert when a provider begins issuing a key type that the client has not tested. During key rotation, validate the new key and its parameter set before enabling the algorithm for production.

Test a token with the right signature and wrong at_hash, a token with the right hash and wrong audience, and an EdDSA token whose key curve changes. These cases separate signature validation from claim binding. They also catch a client that accidentally validates only the happy path.

The hash claim is a small field with a narrow job. It ties one token value to one signed identity response in one flow. Implement that job precisely, and leave authorization to the claims and policies designed to carry it.

References

Greenplum discovery has to distinguish the database, the master, and the console

yutianle — Sun, 15 Nov 2026 08:23:19 +0000

Greenplum discovery has to distinguish the database, the master, and the console

Greenplum is a distributed analytical database built from a coordinator and segments. A public page that carries its name may describe the database, a client library, a command center, or a deployment guide. The security review must find the actual PostgreSQL-compatible endpoint and the administrative path around it.

A count-only ZoomEye probe on November 15, 2026 used sub_type=all, page 1, and page size 1. app="Greenplum" returned 3, title="Greenplum" returned 292, and http.body="Greenplum" returned 2,365. These are index observations. The body count can include documentation and package pages, and the title count does not prove that a database is reachable.

Start at the coordinator

The master or coordinator controls client access to the cluster. Its pg_hba.conf rules define which database, role, address, and authentication method can connect. Segment configuration normally restricts client connections to the coordinator. Review the coordinator's rules first, then confirm that segments do not accept the same external client path.

Greenplum uses roles to manage database access. Inventory superuser roles, login roles, group memberships, and object privileges. A role with broad read access can reach every analytical dataset that the cluster hosts. A role that can create functions or extensions may have a much larger authority than a reporting user.

Separate management from query access

A command center or web console is a management plane. It may reach multiple clusters and hold database credentials. The console URL, its identity provider, its users, and its stored cluster list need separate review from the SQL endpoint.

Use TLS for remote SQL connections and verify the server certificate. If Kerberos or LDAP is available, document the exact authentication path and the fallback behavior. A fallback to a broad password rule can bypass a carefully designed directory policy.

Turn matches into owners

For each title or body match, identify the organization and the product context. A documentation page is not a coordinator. A confirmed endpoint should have a host, port, database name, server version, role owner, TLS state, and application dependency.

Bound the data sample used during validation. Analytical databases often contain customer, financial, or operational records. Do not run broad queries or export rows from a host you do not own. Record the endpoint and configuration evidence instead.

Operate the boundary

Rotate the credentials used by the console and by ETL jobs separately. Log connections with role, database, source address, and result, but do not log statements that contain sensitive values. Review grants after every new data source or reporting application. A Greenplum coordinator can be a single credential path to many datasets, which makes role review more important than the product count.

The small application count is not a low-risk conclusion. It means the fingerprint needs corroboration. Find the coordinator and its management console, then establish who can query and who can administer the cluster.

References

Unknown Protobuf Fields Need a Boundary Before They Reach Internal Services

yutianle — Sun, 15 Nov 2026 05:03:38 +0000

Unknown Protobuf Fields Need a Boundary Before They Reach Internal Services

Protocol Buffers are designed for evolution. A parser that does not recognize a field can retain it and write it back when the message is reserialized. The language guide documents this retention behavior for proto3 and proto2. It is a useful compatibility property: an old service can modify a message without destroying fields that a newer service understands.

That same property changes the meaning of validation in a multi-service path. A public gateway may parse a request into a current message type, inspect the fields it knows, and forward the reserialized object. Unknown fields carried through the gateway can reach an internal service with a newer schema that gives them meaning. The gateway has effectively forwarded a command it never authorized.

Validation is schema- and boundary-dependent

The risk is not that unknown fields exist. The risk is that a component claims to validate a message while preserving fields outside its validation model. If the design requires a closed command, the boundary should reject unknown fields or strip them before forwarding. If forward compatibility is required, the receiving service must apply authorization to every field it interprets, including fields that the gateway did not see.

The issue becomes sharper when the gateway maps protobuf into a second representation. A proxy may convert a message to JSON, drop unknowns, and reconstruct it later. That can be safe, but only if the transformation and the receiving schema agree about field presence and defaults. Proto3 serialization is not canonical, so a byte comparison of messages is not a safe substitute for semantic validation and authorization.

Do not use a protobuf hash as a signature over a partially validated request. Field ordering, unknown fields, and encoding choices can produce different bytes for the same logical message. Authenticate the transport and the signed payload under a documented canonicalization rule, then validate the decoded command against a schema and an authorization policy.

Design options

The most conservative public boundary uses a dedicated request message that contains only the fields the public API supports. The gateway validates it, authorizes the caller, and constructs a new internal command from named fields. Unknown fields are discarded by construction rather than by a fragile recursive strip.

An internal compatibility boundary can preserve unknown fields, but it should be an explicit contract. The internal service owns authorization for the full message version it accepts. It should not trust a gateway assertion that a message was already validated if the gateway's schema is older than the receiving schema.

Record the schema version and descriptor hash at each tier. Add tests that send a field understood by the downstream service but absent from the gateway schema, then verify the resulting authorization decision. Test an unknown field that changes a oneof or enum value, and test a message that round-trips through each language runtime used by the system.

Operate the schema as code

Schema changes should go through the same review as code. Mark removed fields as reserved, document compatibility expectations, and review new security-sensitive fields with the services that will interpret them. A field named is_admin, tenant_id, or actor deserves a dedicated threat review even if the public gateway cannot currently set it.

Unknown-field retention is not a vulnerability by itself. It is a warning that a message may mean more than one component thinks it means. The security boundary should be explicit about where unknowns stop, which service interprets them, and how the authorization layer learns about them.

References

An Otter Wiki Proxy Header Can Carry More Than an Identity

yutianle — Sun, 15 Nov 2026 01:43:22 +0000

An Otter Wiki Proxy Header Can Carry More Than an Identity

An Otter Wiki is a small self-hosted wiki built with Python, Markdown, and Git. The first account created in a deployment becomes an administrator. The project also supports proxy-header authentication, which lets a reverse proxy supply the authenticated user and a permission list.

The ZoomEye measurement on 15 November 2026 found 0 matches for app="Otterwiki", 2 for title="Otterwiki", and 267 for http.body="Otterwiki" with sub_type=all, page 1, and page size 1. These are very small discovery counts. The body result can include documentation and package pages, so it should not be read as two hundred live deployments.

The proxy must overwrite the header

Otter Wiki's configuration documentation describes AUTH_METHOD='PROXY_HEADER' and an x-otterwiki-permissions header whose accepted values include READ, WRITE, UPLOAD, and ADMIN. That design is only safe when the reverse proxy removes any client-supplied value and writes the trusted identity and permission headers after successful authentication. A proxy that appends to the request or preserves unknown headers can let a caller choose its own permissions.

The header set is an authorization decision, not a display name. The proxy and the wiki must agree on the possible values, the default when no header is present, and the behavior for an invalid value. Test each permission and confirm that WRITE does not imply ADMIN, that an anonymous request cannot upload, and that a revoked identity loses access immediately.

The first administrator should be created through a controlled setup and removed from the bootstrap path afterward. Review registration, password recovery, user administration, and the Git server integration. The repository-management documentation notes that users with READ can pull and users with UPLOAD can push when the Git server is enabled. That turns repository access into a second permission surface.

Inventory the content path

List the wiki hostname, version, authentication mode, proxy identity source, administrator, Git server state, storage location, and backup policy. Review custom templates and injected HTML because the wiki renders content for other users. Check whether attachments and repository remotes can reach internal addresses or execute deployment hooks.

The title count is not enough to identify the deployment, but the configuration question is clear. If the wiki trusts a header, the network path to the wiki must be limited to the proxy that sets it. A reverse proxy with permissive header forwarding can turn a logging or SSO integration into an administrator path.

References

Datasette Default Permissions Turn a Data File Into an Exposure Surface

yutianle — Sat, 14 Nov 2026 22:21:02 +0000

Datasette Default Permissions Turn a Data File Into an Exposure Surface

Datasette publishes SQLite data through a web interface and API. Its default view permissions are permissive, which means the first security question is not whether the product is identifiable but whether the database was meant to be public. A bounded ZoomEye run on November 15, 2026 returned 224 matches for app="Datasette", 484 for title="Datasette" and 928 for http.body="Datasette". All queries used sub_type=all, page 1 and page size 1.

The application fingerprint is still not a deployment count. It is a field-level observation that can include documentation, demos, a hosted catalog, or a real instance. The title and body counts add different leads. For an owned domain, a successful app match is a good reason to verify the serving process and the database path, not a reason to assume data is exposed.

Datasette's authentication documentation explains that built-in view actions default to allow unless additional permission rules are configured. The --default-deny option denies anonymous and unauthenticated access, and explicit rules can grant view, query or write actions to named actors. API tokens are available through built-in and plugin mechanisms. This makes authentication and per-resource authorization two separate checks.

Review every database and table, not just the landing page. A public table can reveal row counts, columns and content even when write actions are disabled. A read-only token can still expose sensitive rows. Use a deny-by-default configuration for private data, grant only the view or query actions required by the application, and keep a separate privileged token for maintenance.

The root login URL is single-use, but it is also a powerful bootstrap credential. Treat it as an administrative secret and rotate or disable it after setup. Put the service behind a network boundary when the data is not intended for the open internet, and log token use without recording the token.

Test an anonymous instance request, an anonymous table request, a token with the wrong database, and a revoked token. The expected result is a clear 401 or 403 before SQL execution. The 224 app matches show that this fingerprint is useful. They do not replace a content owner's decision about which SQLite files belong online.

References

Apache Sling title matches are a starting point for XSS-helper review

yutianle — Sat, 14 Nov 2026 19:04:54 +0000

Apache Sling title matches are a starting point for XSS-helper review

Apache Sling is a Java web framework for content-centric applications. Many sites expose the framework through application paths, author interfaces, or a generated title. A November 2026 advisory describes CVE-2026-123765 in Apache Sling XSS before version 2.4.14. The flaw is a cross-site scripting issue where xssAPI.getStyleToken() accepts markup in unquoted URLs.

A ZoomEye count-only observation on 15 November 2026 returned 0 for app="Apache Sling", 189 for title="Apache Sling", and 1,162 for http.body="Apache Sling". The scope was sub_type=all, page 1, page size 1.

The title result is small enough to review as a candidate set. It is still not a deployment census. A page title can be set by a template, copied by documentation, or shared by an application that uses Sling in only one component. The application count was zero in this snapshot, so the body and title markers provide the handholds.

The XSS helper is a library inside an application. A public page does not reveal whether a specific template calls getStyleToken() or whether an unquoted URL reaches the vulnerable function. The owner needs the Sling XSS dependency version and the code path that builds style tokens.

Verify the application and dependency

Match title and body candidates to DNS inventory, certificates, content owners, and application teams. Confirm that the host serves a Sling-based application. Record the application URL, visible version if any, authentication method, and development owner.

Search source manifests and application bundles for org.apache.sling.xss and the affected release range. Check transitive dependencies and custom bundles. A site can run a recent Sling platform while retaining an older XSS helper package.

Review templates that call getStyleToken() and any code that builds URLs without quoting. Trace user-controlled inputs into the helper. Test with harmless markup in a staging environment to verify that the rendered response is encoded.

Upgrade and constrain

Upgrade Apache Sling XSS to 2.4.14 or later. Rebuild the application bundle and restart the services that load it. Confirm the resolved package version in the runtime.

If the helper does not need to accept markup, reject it at the input boundary. Use a strict URL parser and an allow-list for schemes and hosts. Apply a Content Security Policy as defense in depth, but do not use it to excuse an unpatched server-side encoder.

Review exposed content

Look for editorial forms, style selectors, rich-text fields, and URL parameters that reach getStyleToken(). Review the application's session cookies and administrative actions. A cross-site scripting issue can turn a seemingly low-severity content flaw into account actions performed by a privileged editor.

After the upgrade, test normal styles and a malicious unquoted URL fixture. Confirm that the output is encoded or rejected and that the template still works. Record the dependency version, affected templates, test result, and owner.

Keep the search honest

A title match is a candidate for version verification, not proof that the XSS helper is exposed. The selected title="Apache Sling" count of 189 is useful because it is narrow, but it remains an index observation. The 1,162 body matches are a broader lead source.

Use the counts to find owned applications. Use the package inventory and template review to decide whether the XSS path is reachable. That separation keeps a manageable public search from turning into an unsupported vulnerability claim.

References

Reducing Zimbra Classic Web Client Exposure Without Breaking Mail

yutianle — Sat, 14 Nov 2026 15:41:31 +0000

Reducing Zimbra Classic Web Client Exposure Without Breaking Mail

CVE-2026-10632 sits inside the Zimbra Classic Web Client document editor, not in the mail transport path itself. That detail helps administrators choose temporary controls. A team can restrict the vulnerable browser surface while keeping mail delivery, SMTP, and approved client access running.

The flaw is a reflected XSS in the /h/rest editor. The packages parameter is inserted into script attributes without HTML encoding. CVE-2026-50053 adds request-attribute override behavior, allowing a crafted URL to execute JavaScript in another signed-in user's session. The victim has to open the URL, and the attacker needs an ordinary Zimbra account. NVD records CVSS 3.1 8.7 High and affected versions below 10.1.17 in the CVE record.

Find the real browser surface

Inventory every route that serves Classic Web Client content. Include direct mailbox servers, load-balanced front ends, disaster-recovery systems, regional proxies, and any legacy hostname retained for compatibility. Confirm whether /h/rest is reachable through each public and internal path.

Separate user groups that need Classic features from those that can use Modern or a supported mail client. Document editor, Briefcase, and other Classic workflows may be essential for some teams. Treating all users as interchangeable can turn a security restriction into an outage or force an exception that bypasses the control.

Choose controls that match the risk

An internet restriction on Classic Web Client endpoints can reduce the chance that an external attacker delivers the crafted URL to an exposed session. Split-horizon access, VPN enforcement, and an allowlist at the reverse proxy are examples of deployment-specific controls. Each one needs testing against normal mail use and a clear exception process.

A web application firewall rule can flag or block suspicious /h/rest requests containing a packages parameter. The rule must allow legitimate document-editor traffic where it is needed. Start in detection mode, review false positives, and tune against actual paths. A generic XSS signature may not understand the token and document relationship at the center of this CVE, so blocking should not be the only response.

Keep mail operations stable

Do not disable SMTP, IMAP, POP, or supported desktop clients as a shortcut. They are not the vulnerable endpoint described by the CVE, and broad disruption creates pressure to reverse protective controls. If security teams need a maintenance window, coordinate it with mail operations and user support so exceptions and rollback steps are known.

Session management deserves specific attention. Verify that administrators can revoke active web sessions and that the process is documented. Review how delegates, application passwords, and shared accounts are treated. A temporary access restriction that leaves a compromised session active only changes where the session can be reached.

Return to the patched service

ZCS 10.1.17 is the remediation release named for CVE-2026-10632. Upgrade every reachable Classic Web Client path to 10.1.17 or a later supported security release, then verify the running build. Remove temporary proxy rules and legacy routing exceptions when they are no longer needed.

Exposure reduction buys time; it does not replace the fix. The closure record should name the vulnerable routes, the temporary controls, the owner of each exception, the patched build, and the test showing that users can reach the approved service. That record gives the next administrator enough context to prevent an old compatibility path from reappearing unnoticed.

References

GlobalProtect RADIUS Challenge Path Underlies PAN-OS CVE-2026-0327

yutianle — Sat, 14 Nov 2026 12:22:49 +0000

GlobalProtect RADIUS Challenge Path Underlies PAN-OS CVE-2026-0327

CVE-2026-0327 is a privilege escalation issue in the GlobalProtect gateway of PAN-OS. Palo Alto Networks says an authenticated, lower-privileged user can obtain the privileges and configuration of a higher-privileged user. The vulnerability is exposed when a GlobalProtect gateway uses a RADIUS authentication profile that issues a supported authentication challenge.

The vendor published the advisory on November 11, 2026. Cloud NGFW and Panorama are not affected. Palo Alto Networks reported no awareness of malicious exploitation.

Why the configuration condition is central

The rating data is easy to misread. The CVSS 4.0 base score is 6.0, but the vendor's threat score is 2.3. The threat score reflects low reported exploit maturity and specific attack requirements. The base score still describes a network-reachable integrity and privilege boundary.

Administrators should inventory every GlobalProtect gateway, then follow the client authentication reference to its authentication profile. Confirm whether that profile uses a RADIUS server profile and whether the server can issue a supported challenge. A gateway that uses SAML or a certificate profile is not exposed through the same path.

Affected releases

The affected PAN-OS ranges were below 12.2.4-h2, 12.1.10-h4, 11.2.16-h2, and 11.1.16-h5. Fixed releases are the same listed hotfix levels. Prisma Access 12.1 before 12.1.10-h4 was affected and is scheduled for vendor maintenance; Prisma Access 11.2 was listed as affected in full. Older unsupported PAN-OS versions need an upgrade to a supported fixed release.

Mitigation without breaking access

Palo Alto Networks recommends changing the gateway's client authentication to a non-challenge profile, such as SAML, or assigning a certificate profile to enforce client certificate authentication. These changes affect the login experience and may require identity-provider coordination.

Test the change with a small set of users and devices before committing it to all gateways. Record the previous authentication profile so the rollback path is explicit. A temporary mitigation should have an owner, an expiry date, and a monitoring check that confirms the intended profile remains active.

Privilege review

This vulnerability concerns privilege and configuration access after authentication. Review the roles assigned to GlobalProtect users, the configuration scopes available to those roles, and the accounts that can change gateway authentication profiles.

Look for unusual changes to administrator roles, configuration exports, and authentication profile references during the exposure window. A successful exploit may appear as legitimate authenticated activity, so identity logs and management-plane audit logs need to be joined by user, source address, and time.

Response checklist

Inventory all GlobalProtect gateways and their client authentication profiles.
Identify RADIUS-backed, challenge-capable profiles.
Patch to the fixed release or apply the vendor mitigation.
Confirm the running release on every firewall and HA peer.
Rotate credentials if management audit or configuration access suggests compromise.

The issue does not justify removing GlobalProtect from service without evidence. It does require knowing which gateways depend on the vulnerable authentication behavior and which administrators could be reached through the resulting privilege boundary.

References

Palo Alto Networks advisory for CVE-2026-0327

GlobalProtect Title Volume Requires a Narrower Exposure Question

yutianle — Sat, 14 Nov 2026 09:03:40 +0000

GlobalProtect Title Volume Requires a Narrower Exposure Question

CVE-2026-0327 affects the GlobalProtect gateway in PAN-OS when an authentication profile uses a RADIUS provider and issues a supported challenge. The vulnerability is a privilege boundary issue for authenticated lower-privileged users. Internet measurement can find GlobalProtect-related pages, but it cannot prove the authentication profile behind those pages.

At 2026-11-14 07:48 Asia/Shanghai, using sub_type=all, page 1, and page size 1, ZoomEye returned:

app="GlobalProtect": 610 matches.
title="GlobalProtect": 1,242,532 matches.

The gap is large enough to make the reporting lesson obvious. A title match is useful for discovery and very weak as a count of exposed gateways.

What the title count captures

title="GlobalProtect" asks ZoomEye for pages whose HTML title contains the term. That can include portals, login pages, product documentation, support articles, and pages that mention the service. The result is a search-engine observation, not a verified inventory of GlobalProtect gateways.

The app count is narrower and still does not establish the RADIUS challenge configuration. It may include public management or portal interfaces that ZoomEye classified with the application label.

The vulnerability condition

The vendor says the affected configuration is a GlobalProtect gateway whose client authentication profile uses a RADIUS provider and can issue a supported challenge. Changing the profile to SAML or using a client certificate profile is listed as a mitigation. Patching to 12.2.4-h2, 12.1.10-h4, 11.2.16-h2, or 11.1.16-h5 is the permanent fix for the listed branches.

An internet-facing portal is a useful lead because it can expose the gateway's authentication workflow. It is not evidence that the RADIUS condition is present. That requires configuration inspection.

Building a useful list

Use the ZoomEye result to identify candidates for ownership review. Then locate each candidate in the PAN-OS inventory and open its client authentication configuration. Record the authentication profile, RADIUS provider, and whether a supported challenge is issued.

For external attack-surface programs, do not test authentication bypass or privilege escalation against systems outside the authorized scope. The query is a discovery aid, not permission to probe.

Comparing counts responsibly

The 610 application matches and 1,242,532 title matches are not two estimates of the same population. They are different fields with different semantics. Reporting them as a range would be misleading. The better report says the title field is broad, the application field is narrower, and neither field identifies the vulnerable configuration.

Conclusion

ZoomEye provides a useful view of where GlobalProtect content appears on public web assets. It does not replace configuration inventory. The next step is to join the discovered candidates with PAN-OS asset records and authentication-profile evidence.

References

Structured Fields Need One Parser at Every Trust Boundary

yutianle — Sat, 14 Nov 2026 05:42:33 +0000

Structured Fields Need One Parser at Every Trust Boundary

HTTP fields are often parsed by several components before an application sees a decision. A proxy may inspect a cache directive, a gateway may check a signature and an origin may parse the same bytes for authorization. If those components disagree about whitespace, duplicate members, parameter order or type conversion, the system can enforce one meaning while acting on another.

RFC 9651 defines Structured Field Values for HTTP. It provides typed Items, Lists and Dictionaries with a precise parsing and serialization model. A field definition can specify an Item, List or Dictionary and can constrain parameters. The benefit comes from shared behavior, not from placing quotes around a value and calling it structured.

The trust-boundary problem is easiest to see in a signed request. A signer canonicalizes selected fields and sends a signature. A verifier must reconstruct exactly the same component values using the same field type and canonical form. If the verifier treats a dictionary-like string as opaque text while the signer uses the structured serializer, a duplicate key or changed whitespace may produce a valid signature over a different policy interpretation.

RFC 9421 uses Structured Fields where available to make HTTP Message Signature component values deterministic. Even outside signing, the same principle applies to cache controls, authentication metadata, tracing policy and custom gateway fields. One parser should produce a validated data structure, and every downstream policy should consume that structure.

Practical controls begin with field definitions. Reject values that the selected field type does not allow. Decide whether duplicate dictionary keys are an error, last-value-wins or a policy violation. Limit total length, list members and depths so a parsing error does not turn into an unbounded allocation. Record the normalized value that the security decision used.

Do not compare a signature or policy against a hand-built concatenation of raw header text. Use the library's canonical serializer and confirm that all components are present, unambiguous and allowed for the request context. Header names are case-insensitive, but Structured Field member keys and some tokens have their own rules. String case is data, not a normalization convenience.

Proxy chains need a named owner for each field. If a gateway strips a client value and writes its own, the origin should not accept the client's version as equivalent. If a component is not understood, forwarding it unchanged can be safer than guessing, but the security policy must state whether unknown structured parameters are ignored or rejected.

Tests should include quoted strings with escaped characters, duplicate dictionary keys, invalid bare tokens, byte sequences, parameters in different orders and values near configured limits. Send the same bytes through each proxy and compare the parsed decision object. A test that only checks the final HTTP status can miss a parser disagreement when both paths happen to deny a different reason.

Structured Fields reduce ambiguity when the whole chain adopts the type model. The remaining risk is governance. A field without a defined type, a second unofficial parser or a component that rewrites values without recording the change can defeat the benefit. Put the parser and normalization rules under version control, expose their output to tests and review changes as security-sensitive code.

References

ApostropheCMS: Public Pages Do Not Describe the Editing Plane

yutianle — Sat, 14 Nov 2026 02:20:12 +0000

ApostropheCMS: Public Pages Do Not Describe the Editing Plane

ApostropheCMS combines an in-context administrative interface with a headless REST API. A public site can therefore carry Apostrophe branding, editorial output and an API route while exposing no administrative login to an external scanner. The difference matters when a small title count is used to describe the editing plane.

A count-only ZoomEye comparison on 2026-11-14 used page 1, page size 1 and sub_type=all.

Query	Matched assets
`app="ApostropheCMS"`	0
`title="ApostropheCMS"`	18

The exact app label produced no matches. The title label produced 18. Neither result is a count of public admin interfaces. The zero may mean that the exact application value is not present in the selected data, while the title set may include documentation, agency pages and sites that use Apostrophe for content without exposing the editor.

Apostrophe's documentation describes a Node.js server, a Vue-based admin UI, in-context editing and a REST API. The login mechanism is used by the admin interface, and the documentation notes that sessions and bearer tokens serve different client patterns. A public page returning content does not reveal whether those authentication paths are reachable or correctly scoped.

The platform can also run headless, with a separate frontend consuming the API. That pattern removes many visual signs of Apostrophe from the public site. A title search may miss the deployment, while an API endpoint may be present on a hostname with no brand text. The inventory needs host and route evidence, not only visible product names.

The 18 title matches are small enough to treat as a research queue rather than an exposure count. For each match an analyst can ask whether the site owns the content platform, whether an editor login is public and whether the API is meant to be public. Those questions require authorization and technical verification. The count itself does not answer them.

When the app and title labels both have limited coverage, the next useful step is to compare known deployments. Collect response headers, script assets, login paths and API behavior from an owned Apostrophe instance. Build a narrowly defined signature and test it against the small known set. Keep any new label provisional until it produces consistent results.

The absence of an app match is not a low-exposure rejection. A product can be deployed behind a custom frontend, a CDN or an authentication gateway. Conversely, a title match can be a marketing site with no application behind it. The safe interpretation is that the selected fields did not establish the software identity.

For defenders, the review should separate content exposure from editing exposure. Public content may be intentional. Editor authentication, API keys and unpublished content need a different permission model. A small external count should direct attention to those controls, not replace an inventory of the organization's own CMS hosts and roles.

The report should say exactly what was observed. Zero exact app matches and 18 exact title matches at a fixed time is reproducible evidence. It is not evidence that Apostrophe has no public admin planes. The gap between those claims is the analysis the article is meant to preserve.

References

Db2 service and port counts need the same authentication boundary

yutianle — Fri, 13 Nov 2026 23:02:01 +0000

Db2 service and port counts need the same authentication boundary

IBM Db2 commonly listens on TCP 50000 for client connections. In a count-only ZoomEye probe on 2026-11-13 around 22:45 UTC, service="db2" returned 1,519,594 matches and port="50000" returned 5,043,336. Both used sub_type="all", page 1, and page size 1.

The large difference is a reminder that port numbers are conventions. A service on 50000 is not necessarily Db2, and a Db2 service can be moved or proxied. The service query is a stronger protocol clue, but it still does not prove that a client can authenticate or that a database is misconfigured.

Db2 is a management and data-plane boundary. A reachable listener can reveal connection behavior, service names, or version information depending on configuration. The database accounts, authentication method, network policy, and workload permissions remain separate controls.

What the port proves and what it does not

The port query establishes that the conventional endpoint answered in the index. It does not establish that the process is a Db2 server. It also does not show whether the listener requires a user ID and password, whether TLS is configured, or whether the database is reachable from the internet or only from a collector with a particular vantage point.

The service query identifies matching protocol behavior. It can include assets on non-default ports, but it may miss a server that does not produce a recognizable banner. The two counts should be used together. A service match on the expected port is higher-confidence evidence than a bare port observation.

IBM documentation describes 50000 as the standard client port and 50001 as a common SSL port. An inventory should state whether it measured one or both. A total that mixes secure and non-secure endpoints without that distinction is harder to act on.

Review the listener and the database separately

The first review is network placement. Restrict the listener to the application networks that need database access. Avoid exposing a shared database service directly to the internet. If remote access is required, place it behind an approved access path and monitor the connection source.

The second review is authentication and transport. Confirm whether TLS is required, which certificates are trusted, and how client identities are mapped to database users. Review account policy and least privilege separately. A listener with encrypted transport can still front an overprivileged account.

The third review is service ownership. Record the instance, database name, application, backup path, and decommission state. Retired databases often leave a listener or a firewall rule behind. A scan can find the port but cannot tell whether the business still depends on it.

Turn the number into a bounded queue

Use the service query for a higher-confidence candidate list and the port query for a broader reachability check. For each owned candidate, capture the host, port, protocol classification, TLS status, authentication policy, and owner. Compare 50000 and 50001 if both are relevant.

Run a connection test from an unauthorized source and verify that it fails before authentication. Then test the intended application path. Do not attempt password guessing or data access beyond the approved test. If the database is retired, remove the listener and the network rule together, then re-run the same query.

The 1.5 million service matches and 5.0 million port matches are not a claim that every endpoint is an exposed database. They show why a default database port requires careful interpretation. The security decision belongs to the owner who can confirm the process and the authentication boundary.