DEV Community: facilishz

Python tarfile extraction needs an explicit filter policy

facilishz — Wed, 04 Nov 2026 13:02:06 +0000

Python tarfile extraction needs an explicit filter policy

An archive extractor turns bytes supplied by someone else into filesystem writes. That makes every extraction path a write primitive, even when the code never runs a shell command. Python's tarfile module now exposes a set of extraction filters for this problem, but a service still has to select one and keep that choice stable across supported Python versions.

The unsafe part is the destination path

A tar archive can contain ordinary files, symbolic links, hard links, device nodes, absolute paths, and members with .. components. An extractor that trusts those names can write outside the intended directory or create a link that makes a later write escape it. The archive format does not carry a promise that every member belongs under one clean root. The application has to enforce that rule.

The Python 3.12 documentation supplies tarfile.data_filter for data archives and also documents privileged filters for archives that need broader behavior. The data filter rejects paths that escape the destination, blocks unsafe links, and rejects special files. Applications that only need regular files and directories should prefer the narrower behavior.

Make the filter visible in the call

An explicit argument is easier to audit than a global side effect:

import tarfile

with tarfile.open(archive_path, "r:*") as archive:
    archive.extractall(
        path=destination,
        filter="data",
    )

Code that carries a custom policy can pass a callable instead. A callable should inspect the member and return either a safe replacement member or None. It should reject absolute paths, parent traversal, unexpected device files, and links whose resolved destination is outside the extraction root. Raising an exception is often clearer than silently skipping a hostile member because the caller then knows that the transaction did not complete as expected.

Version defaults still need an inventory

The filter interface is available on supported branches, but defaults differ by Python release. A service that relies on the interpreter default can behave differently after a base image upgrade. Use hasattr(tarfile, "data_filter") to check feature availability, then set extraction_filter or the filter argument explicitly in code. Do not use a version number as the only capability test when the runtime has been patched or rebuilt by a distribution.

There is another operational detail in the documentation: an extraction that aborts can leave a partial tree. Treat the destination as untrusted until the whole operation succeeds. Extract into a fresh staging directory, validate the resulting tree, and move it into place only after success. That prevents a failed request from leaving files at paths that a later process mistakes for valid state.

Controls that survive a retry

Use a dedicated unprivileged account for extraction. Mount the staging area with nodev, nosuid, and noexec when the extracted content does not need those capabilities. Apply a file count and total expanded size limit before accepting the request. Keep the archive and the extracted output on the same controlled volume so a rename is atomic. Log the parser version, selected filter, member count, expanded bytes, and failure reason.

These controls do not prove that every file is harmless. They make the extraction boundary predictable and give the next process a clean object to inspect. The filter is part of the security model, not a decoration on the extractall call.

References

[1] Python 3.12 tarfile documentation

[2] Python tarfile extraction filter documentation

FOSSology title matches mark a small license-review surface

facilishz — Wed, 04 Nov 2026 09:41:53 +0000

FOSSology title matches mark a small license-review surface

License scanning systems sit beside source code, build artifacts, supplier packages, and legal decisions. That makes them useful reconnaissance targets even when their public footprint is small. A count-only ZoomEye query found no application fingerprint for FOSSology but 28 title matches on 2026-11-04. The result is a lead for asset review, not a vulnerability finding.

What the observed surface represents

The query app="FOSSology" returned 0. The complementary query title="FOSSology" returned 28. Both ran with sub_type=all, page 1, and pagesize 1 at 07:49 Asia/Shanghai. The page size limits returned records; the reported total is the match count. The zero app result does not prove that no FOSSology instance is exposed. It means ZoomEye's application fingerprint did not identify one in this query.

The title count is also not a count of organizations. A reverse proxy, a themed login page, or a documentation mirror can produce a title. A single organization can expose several assets. Treat the number as a population estimate for an inventory task and verify ownership before drawing conclusions.

Why the system deserves its own inventory

FOSSology supports license and copyright analysis through a web interface and REST API. Its API documentation describes token-based access, and the current project documentation notes OpenID Connect authentication options. The sensitive material is not only the scanner configuration. Uploaded source packages, scan results, report links, and integration tokens can reveal suppliers, unreleased products, and software composition.

An internet-facing instance may be intentional for a distributed legal or engineering team. The review question is whether the public endpoint needs to serve every function. A read-only report portal can have a different exposure profile from an administrative scanner that imports source packages. Separate the routes if the application permits it, or place the administrative console behind a private access layer.

Checks that produce evidence

Start with the public hostname and its TLS certificate. Identify the owning business unit, the environment, and the deployment version. Authenticate through the intended flow and list users, API tokens, and integration clients. Confirm that anonymous users cannot list uploads, reports, jobs, or agent status. Check the upload path for file-size limits and a private staging volume.

Review the API token scope. A token used by a build pipeline should not be able to create administrators or read unrelated projects. Rotate tokens after staff changes and record their owner. If OpenID Connect is enabled, verify issuer, audience, redirect URI, and group mapping against the identity provider.

Monitor authentication failures, upload activity, report downloads, and changes to external integrations. A small service still needs an owner and an alert path. A 28-title population can be checked manually if the inventory is prioritized by certificate name, organization, and title consistency.

Read the count correctly

The useful conclusion is narrow: this query identified 28 title-bearing assets and no application fingerprint. It does not establish that those systems are vulnerable, unpatched, or even running FOSSology. It does establish a set of names and pages that deserve an ownership check. ZoomEye is the discovery layer here. Configuration review and authenticated testing are separate work.

References

[1] FOSSology REST API documentation

[2] FOSSology Python client and authentication notes

[3] ZoomEye result for title="FOSSology"

Tomcat RemoteIpValve needs a trusted proxy boundary

facilishz — Wed, 04 Nov 2026 06:21:23 +0000

Tomcat RemoteIpValve needs a trusted proxy boundary

Applications often use the client address for rate limits, audit records, access rules, and session decisions. Behind a reverse proxy, the socket peer is the proxy rather than the user. Tomcat's RemoteIpValve can recover an apparent client address from a forwarded header, but that transformation is safe only when Tomcat knows which proxies are allowed to supply it.

The valve reads a header such as X-Forwarded-For, identifies internal or trusted proxies, and updates request IP and protocol information. Its configuration includes an internalProxies expression and related trusted-proxy settings. A broad expression can classify an address as trusted when it should not be. An unreviewed default can also be wrong after a network redesign.

What the valve changes

The review should start with the network path. Enumerate every proxy, load balancer, and ingress controller that can connect to Tomcat. Confirm that Tomcat's connector is not reachable from client networks. Then compare those source addresses and ranges with the valve expression. A private-range regex is not a trust policy if an unrelated service on the same private network can reach the connector.

Map proxy trust

Header handling is the next layer. A trustworthy proxy should overwrite or strip client-supplied forwarding headers before adding its own. If the edge passes X-Forwarded-For through unchanged, a client can add an address that Tomcat later treats as part of the chain. The valve's proxy processing reduces this risk only when the immediate peer is trusted and the chain is interpreted as designed. It cannot repair an edge that forwards arbitrary authority headers.

Validation tests

Useful tests include:

Send a forged forwarded header directly to the Tomcat port and confirm that it is rejected or ignored.
Send the same header through the approved proxy and confirm the expected result.
Repeat after adding a new proxy range or changing a load-balancer address.
Check application logs to verify that the recorded client address changes with the tested path.
Review rate-limit keys and allowlists that depend on request.remoteAddr.

Evidence and scheme trust

Audit events should retain both the apparent client address and the immediate peer when possible. If an incident review sees only the rewritten address, it may lose the ability to identify the proxy or detect a malformed chain. The proxy itself should log the original connection and the headers it generated.

A final review point is scheme and port trust. The same valve can influence protocol and host information used for redirects, cookie handling, and URL generation. A forwarded header that is acceptable for logging may be too powerful for building password-reset links or choosing a secure cookie flag. Separate those decisions in the application.

RemoteIpValve is a bridge between a proxy's view of the connection and Tomcat's request API. It should rest on a short, documented list of trusted peers and an edge policy that controls every relevant header. Treating all private addresses as trusted turns a useful adapter into an easy way to forge identity-adjacent request data.

References

Apache Tomcat Valve configuration reference: https://tomcat.apache.org/tomcat-11.0-doc/config/valve.html
Apache Tomcat RemoteIpValve API documentation: https://tomcat.apache.org/tomcat-11.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html

LinkAce bookmarks and API tokens belong in one review

facilishz — Wed, 04 Nov 2026 03:01:42 +0000

LinkAce bookmarks and API tokens belong in one review

LinkAce is a self-hosted bookmark archive. Its records can reveal research interests, internal documentation, customer links, and the URLs people rely on. The service also provides user API tokens and sharing features. A small public footprint can therefore carry a useful map of an organization's information habits.

Observation

At 08:42 on November 4, 2026 (UTC+8), a count-only ZoomEye SDK query with sub_type=all, page 1, and pagesize 1 returned zero application matches for app="LinkAce" and 122 title matches for title="LinkAce". The title matches are a manual verification queue. They may include hosted bookmarks, project pages, or instances with a different application title.

Data and access

The project documentation describes LinkAce as an archive, organizer, and sharing tool for web links. It also documents user API tokens for external applications. Those two facts make the review broader than a login page. A bookmark can be shared without exposing the underlying token, and a token can read or change content without exposing a password. Both need separate ownership.

Start with the account model. Record who administers the instance, how users are created, whether public registration is possible, and which accounts belong to former staff. Then inspect sharing settings. A public or guest-visible collection should be an intentional publication decision, not a side effect of a bookmark's default visibility.

The API review should answer what a token can do. LinkAce's token documentation points to a broad API surface for controlling content. An integration token used by a read-only dashboard should not be able to delete records or change shared collections. If the application does not offer fine-grained scopes, compensate with a dedicated account and network restrictions, and rotate the token when the integration ends.

Review controls

Useful checks include:

Identify the owner of every active API token.
Test revocation against a read-only integration.
Review public, shared, and private bookmark collections.
Confirm that backups and exports are not placed in a web root.
Check whether link previews or webhooks can be directed at internal services.
Record the review time and the visible title count.

The 122 title matches are not evidence of 122 exposed archives. A public page can show a login form, an informational page, or a rendering of the project name. The practical output is a smaller list with a confirmed owner, login boundary, sharing policy, and token inventory.

ZoomEye is useful for finding candidate hosts and for repeating the observation later. It should not be used to inspect private bookmarks or to claim that a public title represents a vulnerable service. The article's conclusion is operational: keep the public face, the sharing decision, and the API authority in the same review, because they describe one information store.

References

LinkAce documentation: https://www.linkace.org/docs/
LinkAce user API tokens: https://www.linkace.org/docs/v2/configuration/user-api-tokens/
ZoomEye title query: https://www.zoomeye.ai/searchResult?q=dGl0bGU9IkxpbmtBY2Ui

BookWyrm: 93 title matches and a federation review that starts with ownership

facilishz — Tue, 03 Nov 2026 23:42:16 +0000

BookWyrm: 93 title matches and a federation review that starts with ownership

BookWyrm is a federated reading community, so its visible surface includes public books, reviews, profiles and federation metadata. On 2026-11-04, ZoomEye returned 93 matches for title="BookWyrm" and zero for app="BookWyrm" with page 1, page size 1 and sub_type=all. The title population is small enough to review by domain, but each result still needs an ownership check.

Federation makes the instance a data boundary

BookWyrm's documentation describes federation as a way for small, trusted communities to connect. The admin interface can show federated instances and control federation settings. That means an instance is not merely a public website. It maintains local accounts, remote relationships and moderation decisions.

Review the federation status, remote instance list and moderation routes. Confirm that only an authorized administrator can change federation settings. Check that remote content is stored with provenance and that a blocked domain does not continue to appear through cached pages or client APIs.

Public reading data is not administrative data

A book page or review can be intentionally public. User email addresses, moderation notes, private reading activity and session data are not. Test these with an owned account and no third-party data. Do not enumerate users or use public API responses to infer private relationships.

Keep database, media storage and reverse-proxy access logs separate from the public request path. A federated delivery job should use the minimum credentials needed for federation, not an administrative account token. Review outgoing requests for SSRF protections if an administrator can add a remote instance URL.

Interpreting the zero application count

The absence of a product application fingerprint can mean the index did not see a stable value. It does not show that the 93 titles are unrelated, nor that the software is unconfigured. Use title matches to group domains by certificate and organization, then verify representative hosts against the documented public pages.

For an owned instance, inspect version, deployment configuration and backup age. For an external instance, limit the review to public metadata and ownership. The title is a clue, not an authorization to probe accounts.

A small-population workflow

Resolve each candidate's public host and owner.
Confirm the expected federation mode.
Review admin and moderation route reachability.
Check storage and backup access for private reading data.
Record the result without collecting user content.

ZoomEye provides a 93-title scope that an organization can compare with its own domains. BookWyrm's federation and moderation documentation defines the controls. The security question is whether the public reading community is separated from the infrastructure that stores private accounts and remote relationship data.

References

[1] BookWyrm documentation

[2] BookWyrm federation documentation

[3] BookWyrm moderation documentation

Scrypted: 2,758 title matches around camera and NVR access

facilishz — Tue, 03 Nov 2026 20:21:34 +0000

Scrypted: 2,758 title matches around camera and NVR access

Scrypted is a home and small-business automation server with a strong camera and NVR use case. It connects to cameras, bridges protocols, records video, and presents a management interface. A public Scrypted instance can expose live camera views, recorded footage, device settings, and the credentials used to reach the cameras.

A ZoomEye count-only query on 2026-11-03 returned 2,758 matches for title="Scrypted" and zero for app="Scrypted". The search used page 1, pagesize 1, sub_type=all. The title result is a candidate inventory, not a confirmed count of exposed NVRs. A login page, documentation page, or unrelated site with the same title can be included.

Camera authority is layered

Scrypted's access documentation describes user management, a Scrypted NVR users extension, per-camera permissions, and optional cloud access. It warns that a compromise in an authentication provider such as Scrypted Cloud, an email account, or a single sign-on service could allow another party to view cameras or modify server settings. That warning is a useful reminder that the internet-facing login is not the only trust path.

The camera connection adds another layer. Scrypted's camera setup guidance says the camera login may need administrator-level access for some functions. A server that stores camera administrator credentials can read streams and change device settings. Use separate camera accounts where possible, apply network restrictions, and avoid exposing the camera management interface directly.

Review who can view footage and who can administer the server. A viewer account should not be able to add a camera, change recording policy, or invite another user. Test permissions on a per-camera basis, not only on the dashboard. If a user is removed from a camera group, confirm that existing streams and mobile sessions lose access.

Separate local and remote access

The documentation describes local network access and optional cloud access. These paths can have different identity providers and session lifetimes. Decide which one is intended for each user. A cloud account that can recover through email may be the weakest link for a camera system, especially if the email account is not protected by strong authentication.

Place the server behind a VPN or an identity-aware proxy for remote administration. If a cloud relay is used, review its sharing model and the permissions granted to each linked account. Check whether recordings are stored locally, on a NAS, or in a cluster configuration, and protect the storage path as part of the same review.

The title count should be matched against known deployments and network ownership. Do not use 2,758 as a claim that thousands of camera feeds are public. Confirm the login page and the organization's intended reachability first. A small camera estate can still contain sensitive views of homes, warehouses, or production floors.

A practical checklist

Record the version, public route, authentication provider, administrator count, NVR plugin status, camera permissions, recording retention, and storage location. Test a viewer against a camera that should be hidden. Test a removed user against the web interface and an existing mobile session. Check whether the server's camera credentials can be read from a backup or configuration export.

Monitor sign-in failures, camera additions, permission changes, and recording exports. Keep the camera firmware and the server's dependencies current. Scrypted may be only one part of the path, but it is often the component that holds the keys to all the others.

Query evidence

title="Scrypted" returned 2,758 matches at 2026-11-03 19:50 UTC. app="Scrypted" returned zero. The observation is a title-matched population, not a confirmed count of exposed camera systems.

Open the recorded ZoomEye search

References

Axios CVE-2026-44494: What Red Hat Customers Should Verify in OpenShift

facilishz — Tue, 03 Nov 2026 17:03:44 +0000

Axios CVE-2026-44494: What Red Hat Customers Should Verify in OpenShift

Red Hat scope

Red Hat's CVE-2026-44494 record identifies a flaw in Axios that can escalate an existing Object.prototype pollution condition into a full man-in-the-middle attack. Red Hat rates the issue Important with a CVSS 3.1 base score of 8.7 and gives the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N.

The affected component is Axios. The GitHub advisory lists versions from 1.0.0 through 1.15.x and identifies 1.16.0 as the patched release. Red Hat lists OpenShift Container Platform among the products that contain the affected library. Its guidance says a product marked affected includes all minor releases unless the advisory states otherwise, and that fixes arrive through Red Hat errata.

What the Red Hat listing means

An affected product listing means Red Hat determined that the product ships one or more affected components. It does not mean every cluster is exploitable. The application still needs a path that pollutes Object.prototype and a later Axios request that inherits the polluted proxy value.

OpenShift customers should separate the platform package from workloads. Red Hat's errata address the packages Red Hat maintains. A customer-built Node.js image can contain its own Axios package, so it must be rebuilt from an updated dependency even after the cluster is current.

The technical path

The HTTP adapter reads config.proxy from the merged request configuration. Because proxy is not in the Axios defaults, an object can have no own property and still inherit an attacker-supplied one. If setProxy() receives that value, it can change the request host and port.

The attacker proxy can see request headers, credentials, cookies, and bodies. It can also replace responses. Red Hat's description states that no direct user interaction is required once an existing pollution primitive is present. The separate pollution source is the main reason the issue is conditional.

Customer verification checklist

List every OpenShift namespace and runtime image digest. Query the final image's package inventory for Axios below 1.16.0. Include applications, jobs, operators, and sidecars. Record the image owner and the request paths that use Axios.

Check the current Red Hat security advisory for the installed OpenShift Container Platform release. Apply the errata that include CVE-2026-44494. Then rebuild application images with Axios 1.16.0 or later and confirm the fixed package inside the new image.

Review object-parsing code for recursive merges and dangerous keys. A team can reduce exposure by rejecting untrusted __proto__, constructor, and prototype keys, but Red Hat says a supported mitigation is not available. Those checks should not be recorded as a replacement for the errata and package update.

Exposure context

The ZoomEye Search title="OpenShift" returned 5,443 matches on 2026-11-03 UTC. The CVE filter returned 0. This count is a broad view of OpenShift-related product titles and should not be compared to Red Hat's affected-product inventory without additional evidence. It does not confirm that a deployment is vulnerable.

References

Managing CVE-2026-21932 in Production Print Environments

facilishz — Tue, 03 Nov 2026 13:41:09 +0000

Managing CVE-2026-21932 in Production Print Environments

Overview

Production print servers sit between job submission, customer files, operator consoles and physical output. An integrity vulnerability in a bundled Java runtime therefore needs a maintenance response even when the public exploit path is incomplete. CVE-2026-21932 affects Oracle Java SE AWT and JavaFX, and Xerox lists it in its January 2026 OpenJDK update for FreeFlow v2 and v7.

Risk profile

Oracle gives CVE-2026-21932 a CVSS 3.1 score of 7.4. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N. The score combines a network attack path, low complexity, no required privileges, required user interaction, changed scope and high integrity impact. Confidentiality and availability are not listed as impacted.

The affected component is AWT and JavaFX. Oracle says the issue applies to clients running sandboxed Java Web Start applications or applets that load untrusted code. The note excludes servers that run only trusted administrator-installed code.

Mechanism and exploitation conditions

The public record does not identify the exact AWT or JavaFX operation that fails. It does establish that exploitation requires network access, user interaction and a client path that loads untrusted Java content in the sandbox model. Xerox links the CVE to the OpenJDK update, but its bulletins do not map the issue to a specific print-server request.

Why integrity matters in print operations

An integrity failure can alter job instructions, configuration data or files that the Java workload can write. The changed scope means the vulnerable component can affect another product or environment. A print server that handles customer artwork or regulated output needs to know which files could be changed and how the resulting print job would be verified.

The absence of a confidentiality impact does not remove the need to protect customer data. It narrows the stated consequence in this CVE. The absence of an availability impact does not guarantee that a damaged job will complete correctly.

Xerox patch scope

Xerox Security Bulletin XRX26-007 puts OpenJDK Java 8 Update 482-b08 into the January 2026 Security Patch Update for FreeFlow v2 on Windows 10. It lists CVE-2026-21932 as remediated and names iGen 5 and Baltoro HF Production Inkjet Press support.

Xerox Security Bulletin XRX26-006 puts OpenJDK 8 Update 482-b08 into the January 2026 Security Patch Cluster for FreeFlow v7 on Solaris 11.4. It lists CVE-2026-21932 and applies to FFPS 73.M1.90 / RV 14.4.28 and later levels.

FreeFlow v9's January 2026 bulletin has no Java software update and does not list this CVE. A production team should not reuse v2 or v7 evidence for v9.

Exposure review

ZoomEye returned 197 matches for title="FreeFlow" and 0 for vul.cve="CVE-2026-21932". The selected Exposure is 197.

https://www.zoomeye.ai/searchResult?q=dGl0bGU9IkZyZWVGbG93Ig%3D%3D

The query gives a list of potentially relevant internet-facing assets. It does not reveal the patch level or prove that a visible console can launch untrusted Java content. Use it to find owners and start an inventory review.

Change plan

Start with the vendor-supported package for the correct FreeFlow release. Schedule the install through the Xerox service process and record a system backup before making changes. During the window, limit access to the server from networks that do not need it.

After the install, verify the OpenJDK build. On v7, Xerox documents a script that reports the Solaris version, FreeFlow release, patch cluster and Java version. Use the equivalent supported verification path on v2.

Keep a before-and-after record for each host. Include the package identifier, the FreeFlow release and the Java version. Restore the vendor-approved backup plan if the package is corrupt or the version check does not match.

Monitoring

Review authentication, administration and job-processing logs for unexpected changes during and after the patch window. Validate a sample of print jobs after the update. Alert on changes to server configuration that do not match an approved maintenance action. These checks help detect integrity problems without claiming that a specific CVE artifact was observed.

References

XWiki Visibility: Turn a Fingerprint Count Into an Owner List

facilishz — Tue, 03 Nov 2026 08:50:10 +0000

XWiki Visibility: Turn a Fingerprint Count Into an Owner List

XWiki is a collaboration platform with pages, extensions, user accounts, and administration functions. An external inventory needs to locate deployments that an organization may have forgotten without turning a product fingerprint into a vulnerability claim. A count is useful when the query, scope, and limitations are recorded with it.

On 2026-11-03, a count-only ZoomEye query for app="XWiki" used scope all, page 1, and one result. The observation returned 1,268 matching assets. The exact time and query are part of the evidence. The result is an observed application-fingerprint population, not a list of confirmed affected versions or a test of whether anonymous page access is enabled.

Why a fingerprint is a useful first pass

A title containing a product name can appear in documentation, tutorials, and unrelated sites. An application fingerprint field provides a stronger relationship between an asset and the product, though fingerprint quality still varies by version and deployment. The count can guide an ownership review and help prioritize hosts that sit outside the expected hosting inventory.

The operator should avoid comparing this number directly with a vendor download count or an internal endpoint count. Those figures answer different questions. ZoomEye measures matching public observations under a selected scope. Internal inventory measures deployed software known to the organization. The gap between them is the interesting part, not a single "exposure score."

Review the actual surface

For each candidate, identify the hosting owner, domain registration, certificate identity, and business purpose. Check whether the wiki serves anonymous content, whether account creation is open, and which extensions are active. Review administrative access and recent user changes. Collect version evidence from an authorized management interface rather than from a remote probe alone.

Do not test exploit paths unless the organization has explicit authorization and a controlled process. Discovery is not exploitation. A public wiki can be intended to be public, and a private wiki can be misconfigured in a way that deserves urgent remediation. Those are different decisions.

Keep evidence comparable

Store the normalized dork, scope, page settings, collection time, and count. If the same query is repeated, record whether asset changes, quota, authentication, or API errors occurred. A failed request is not a zero count. Preserve enough query metadata that another analyst can reproduce the measurement.

ZoomEye's practical value is prioritization. It turns an open question about forgotten XWiki installations into a bounded review queue. The team still needs to verify ownership, authorization, version, and configuration. A completed review should produce an owner list, a remediation decision for each exception, and a follow-up time for any public wiki that cannot be retired.

References

Partitioned cookies contain embedded sessions without flattening tenant isolation

facilishz — Tue, 03 Nov 2026 07:10:53 +0000

Partitioned cookies contain embedded sessions without flattening tenant isolation

Cookies Having Independent Partitioned State, usually called CHIPS, lets a site opt a cookie into storage that is keyed by the top-level site and the cookie's host. The Partitioned attribute changes how a browser stores and returns the cookie. It does not change the application's responsibility to authenticate the user, authorize an object, or separate tenant data.

That distinction matters for embedded portals, support widgets, payment forms, and any application that runs inside another site. A partitioned cookie can prevent one top-level site from seeing another site's copy of the same embedded service cookie. It cannot prevent an application flaw inside one partition, a stolen bearer token, or a server that returns data for the wrong account.

Understand the storage key

MDN describes partitioned cookies as using the host key and a partition key derived from the top-level site. Two top-level sites that embed the same third-party service receive different cookie jars even if the cookie name and host are identical. The Partitioned attribute is set on the Set-Cookie response, and the cookie must also use appropriate security attributes.

The partition key is not a user identity or a tenant identity. It is a browser storage boundary. If the same user visits the same embedded service from two sites, the service may see two independent cookie contexts. If two users share a device and visit the same top-level site, they may still share the browser profile. Design session records and logout behavior from those realities.

Do not use a partitioned cookie as the only source of tenant context. The server should resolve the tenant from an authenticated session, a signed configuration, or a validated host mapping. A request from a different top-level site should not be able to move the session to another tenant merely by changing a cookie name or an embedding parameter.

Plan for compatibility and fallbacks

Browser behavior around third-party cookies differs by vendor, version, user setting, and enterprise policy. Some contexts may reject the cookie entirely. Others may use partitioning only when the attribute is present. A service that depends on a cookie for authentication needs an explicit fallback for a lost cookie, such as a short-lived authorization code or a reauthentication flow.

Test in a real embedded context rather than only at the top-level URL. Check whether the browser sends the cookie, whether it sends it only in the expected partition, and whether a logout in one top-level site affects another partition. Test SameSite interactions, secure transport, and a top-level navigation that changes the embedding site.

If the service uses a cross-site iframe for login, do not weaken the cookie to SameSite=None without Secure and a reviewed domain policy. Do not expand the cookie domain to a parent domain merely to make an embed work. That is a different security tradeoff and can expose the cookie to more subdomains than intended.

Keep authorization on the server

The session should carry the user, tenant, assurance level, and expiry. The server should check the requested resource against that session on every request. A partitioned cookie might distinguish two embedding contexts, but the server still needs a mapping between the embedding context and the authorized tenant.

Use __Host- prefixes where they fit the deployment and help prevent domain and path surprises. Avoid storing personal data or access tokens in cookie values. A random session identifier is easier to revoke and rotate. Set a bounded lifetime, rotate after privilege changes, and invalidate the server session on logout.

Monitor missing-cookie rates by embedding site and browser. A change in partitioning policy can look like a login failure, a session loop, or an unauthorized request. Record the top-level site only when the privacy policy permits it, and aggregate the signal. Do not build a cross-site identifier from partitioned session records.

Treat partitioning as one control

CHIPS is useful when a service needs a cookie in a third-party context and wants to reduce cross-site tracking and cookie leakage. It is not a complete same-origin policy for application data, a substitute for CSRF protection, or a reason to trust an iframe's origin. The application still needs origin checks, CSRF defenses where cookies are used, and server-side object authorization.

The practical goal is to make the browser boundary explicit and keep the security boundary on the server. A partitioned cookie can be a reliable session container when the deployment accounts for compatibility, logout, tenancy, and token theft. It cannot manufacture those properties by itself.

References

MDN Web Docs, Cookies Having Independent Partitioned State (CHIPS)
MDN Web Docs, Set-Cookie header
IETF, RFC 6265: HTTP State Management Mechanism

OpenProject: compare title and app counts before mapping project servers

facilishz — Tue, 03 Nov 2026 05:30:25 +0000

OpenProject: compare title and app counts before mapping project servers

OpenProject supports project planning, work packages, wikis, meetings, and integrations. A public instance can expose project names, timelines, attachments, and user identities. The security question is not whether a page mentions OpenProject. It is whether the instance is owned, whether project data is meant to be public, and whether the administrative layer is separated from the collaboration layer.

What ZoomEye returned

On 2026-11-03T04:15:32Z, with page=1, pagesize=1, and sub_type=all, ZoomEye returned 12,444 total matches for title="OpenProject". At 2026-11-03T04:15:33Z, the corresponding app="OpenProject" query returned 11,684. The two counts are close enough to support a consistent discovery signal, but they still do not prove ownership, version, or public data access.

The app result is a useful primary fingerprint because it is specific to the application and close to the title population. The title result is useful for finding branded or partially fingerprinted deployments. Record both observations with their timestamps instead of choosing a single global count.

Understand the deployment surface

OpenProject's official configuration guidance covers TLS termination, reverse proxy headers, authentication providers, and external SSL. A deployment behind a proxy must tell the application that the original request used HTTPS. Otherwise generated links and secure-cookie behavior can be wrong even though the public URL looks correct.

Authentication can be local or delegated to an identity provider. Review whether local login remains enabled after SSO, how administrators are provisioned, and what happens when an account is removed from the directory. Two-factor authentication can be available, but availability is not enforcement. Check the policy for administrator and project-owner accounts.

Map the project and administrative roles. A project member may read work packages, attachments, and meeting notes. A project owner may change membership or visibility. An instance administrator can reach global settings, integrations, and user data. These roles should not share one broad group.

Review public sharing and integrations

Look for public projects, anonymous access, shared links, and API tokens. A project that is private in the web interface may still have an automation token or an external integration with broader access. Review the token owner, scope, expiry, and last use.

Inspect outbound connectors and incoming webhooks. A repository integration can reveal issue titles to another system. A webhook endpoint can accept data that the application later displays. Validate the receiver's authentication, replay protection, and size limits.

Check file attachments separately from page text. A public project may show metadata while attachments remain protected, or the reverse. Review the storage backend, upload limit, malware scanning policy, and access-control behavior for direct file URLs.

Use the counts as an inventory filter

Join the ZoomEye matches to organization-owned domains and certificate records. For each host, confirm the deployment from an authenticated administrative source. Record the version, authentication mode, public-project policy, and owner. Do not use a count as evidence that a host is vulnerable.

Use a change in app or title count as a discovery trigger. A new match under an owned domain may indicate a new project server or a proxy change. A disappearing match may indicate a rebrand, a new WAF, or a service retirement. Correlate with change records before escalating.

OpenProject is designed to make project information easy to share. That makes the ownership context essential. ZoomEye can show that many pages identify themselves as OpenProject, and the app query gives a tighter starting set. The organization still has to decide which projects are public, which identities may administer them, and which integrations can move their data.

References

OpenProject, Configuring SSL
OpenProject, Authentication
OpenProject, Installation with Docker Compose

CVE-2026-108452 remediation brief for SharePoint Subscription Edition

facilishz — Tue, 03 Nov 2026 03:24:07 +0000

CVE-2026-108452 remediation brief for SharePoint Subscription Edition

The decision for CVE-2026-108452 is straightforward at the policy level: identify affected SharePoint Server Subscription Edition farms, apply KB5002927, verify build 16.0.20326.20190, and record any access restrictions used while patching. The technical details still matter because the vulnerability requires an authorized attacker and can lead to code execution.

Executive summary

Microsoft rates CVE-2026-108452 High with a CVSS 3.1 score of 8.8. It is a CWE-22 path traversal in Microsoft Office SharePoint. An authorized network attacker can execute code, and the vector requires low privileges with no user interaction. Confidentiality and integrity impacts are High.

The affected range is version 16.0.0 through builds below 16.0.20326.20190 on x64 SharePoint Server Subscription Edition. KB5002927, released October 13, 2026, reaches the fixed build. Microsoft Support says farms running SharePoint Workflow Manager must install KB5002799 before the security update and that classic installations need an additional documented debug flag step.

Business risk

SharePoint is often a repository for sensitive documents and a hub for collaboration, workflows, and connected applications. Code execution on the server can affect data confidentiality and integrity, with consequences beyond website availability. The requirement for low privileges lowers the initial access barrier for an attacker who already has a user account or delegated application identity.

The available public record does not establish that the flaw is unauthenticated or that exploitation is widespread. It does establish a network-reachable, low-complexity path to code execution on vulnerable builds. That is enough to place the update ahead of routine maintenance.

Ownership and actions

The SharePoint platform owner should provide the server inventory and confirm farm topology, prerequisites, and final build state. The security operations team should review external exposure, low-privileged and partner access, and monitoring coverage for unusual authenticated activity. The change owner should document maintenance results and exceptions.

Completion requires evidence from every relevant server. A single successful installer log is not sufficient. Capture the build, workflow component state, and date of verification. If a server remains on the exception list, assign an owner, an expiry date, and a network restriction.

Exposure interpretation

ZoomEye returned 163,243 product-fingerprint matches for app="Microsoft SharePoint" on November 3, 2026. The CVE-specific filter returned 0. The broad result is a discovery signal, not a victim count. It cannot prove the installed edition, build, identity exposure, or exploitability of any host.

Use the product count to challenge the internal inventory. Investigate internet-visible SharePoint services that are absent from asset management or cannot produce build evidence. Do not close the item because the CVE filter was zero.

Residual risk

Even after patching, review delegated permissions and application identities. Limit administrative and authoring interfaces to the networks and roles that need them. Monitor for unexpected server-side file changes and unusual requests from low-privileged accounts. The sources do not identify a tested workaround, so these controls should be described as risk reduction while the vendor fix is deployed.

Reporting metrics

Track applicable farms, verified fixed builds, open exceptions, and externally visible candidates awaiting reconciliation. A useful status statement is: "All applicable SharePoint Subscription Edition servers report build 16.0.20326.20190 or later, except these named hosts with restricted reach and dated owners." This is more precise than a percentage based on an uncertain product population.

References

Microsoft Security Update Guide, CVE-2026-108452
Microsoft Support, KB5002927
Microsoft Learn, SharePoint updates
CVE Program, CVE-2026-108452