Posit Workbench provides browser-based development sessions for R, Python, and related tools. A session may have access to source code, data, package credentials, database connections, and files in a user's home directory. Project sharing can extend that access to other users, so an exposed Workbench deployment requires more than a login-page check.
A count-only ZoomEye query on 2026-11-02 returned 1,396 assets for title="Posit Workbench". The query used sub_type=all, page 1, and page size 1. The count identifies matching assets in ZoomEye's data. It does not prove that a shared project is exposed or that a deployment is misconfigured.
The ZoomEye query is an inventory starting point. Confirm ownership before testing any host.
Understand what sharing grants
Posit Workbench documentation states that project sharing gives all project users the same access the owner has to the shared project. Files that were readable only by the owner, such as private keys or sensitive configuration, can become readable by collaborators. The platform uses ACLs to grant access, and the sharing feature is enabled by default.
That behavior is reasonable for a collaborative project. It is a security problem when users share a repository without reviewing files that are not part of the intended collaboration. A .env file, SSH key, cloud credential, database profile, or notebook with a token can cross the same boundary as the source code.
Review the filesystem prerequisites. The documentation requires ACL support and restricts sharing to configured roots. EFS without ACL support is not supported for project sharing, and ordinary file permissions are not modified. The storage layout should reflect those constraints rather than being improvised after deployment.
Control authentication and session access
Workbench supports system accounts, directory services, SAML, OIDC, and proxied authentication. Use an enterprise identity provider with group restrictions and strong authentication. Disable single-user mode on internet-facing production systems. The documentation describes single-user mode as disabling authentication, so it should not be reachable from an untrusted network.
Review the reverse proxy and WebSocket configuration. A proxy that mishandles session cookies or upgrade requests can break project sharing or create inconsistent identity checks. Use TLS, secure cookies, and a trusted proxy range. Verify that an external host header cannot redirect a session to an attacker-controlled domain.
Resource limits are also part of containment. A user session can execute code and consume CPU, memory, and disk. Apply per-user or group limits and monitor unusual process behavior. Restrict access to mounted data and databases so a session compromise does not automatically expose every production source.
Inventory the public deployment
For each candidate host, record the hostname, certificate, address, product evidence, first-seen time, and organization. Determine whether the endpoint is a production Workbench, a documentation site, or a different product. Check authentication and TLS through authorized observation.
Look for alternate hostnames and old deployments. A Workbench migration may leave a legacy server with local accounts or an older proxy configuration. Compare the public certificate and DNS names with the current inventory. Check for an exposed health endpoint or diagnostics page that reveals version or configuration details.
Forward login, session, sharing, and administrative events to an independent logging system. Alert when project sharing is enabled for a project that contains sensitive files, when a new external identity provider is configured, and when an administrator disables authentication or TLS verification.
Test sharing and revocation
Create a disposable project with a file that should remain private, share it with a test account, and confirm the documented access behavior. Remove the collaborator and verify that the ACL entry is removed from the filesystem. Test the project-sharing disable setting and confirm that new shares cannot be created.
Then test the identity path. Revoke the user in the identity provider and confirm that new sessions fail. Check whether an existing session is terminated or must expire. Review the recovery procedure for a compromised account and determine who can terminate active sessions.
The 1,396 ZoomEye matches should be treated as candidate deployments. The important control is the relationship between identity, filesystem ACLs, and session data. Project sharing is a feature, not a quiet file-copy operation. Teams should review what a collaborator will inherit before they add the user.