PrivateBin Incident Response Runbook: What to Do When a Paste Link Leaks

Overview

A PrivateBin link may provide access to sensitive text, logs, configuration details, personal data, or credentials. The URL itself can also be sensitive because some PrivateBin deployments use a URL fragment or other client-held information as part of the decryption process. Do not assume that a link is harmless simply because the paste is encrypted in the browser or has an expiration setting.

The correct response depends on the facts. A link copied into an internal ticket is different from a URL posted in a public repository. A paste containing ordinary troubleshooting notes is different from one containing an API token, production log, or regulated personal information. Begin with controlled triage, then contain access and address any secrets that may have been disclosed.

This process is designed for security teams, developers, IT administrators, and compliance owners. It should complement, not replace, your organization’s incident response plan, breach assessment process, contractual duties, or legal advice.

Immediate decision rule

If you cannot quickly prove that the paste contains no sensitive information, handle it as potentially sensitive. Avoid repeatedly opening the link or forwarding it while investigating. Record the original URL in a restricted incident record, limit access to the responders who need it, and use an approved secure channel for any necessary discussion.

Checklist by scenario

Scenario 1: The link was shared with the wrong person

• Record when the exposure was discovered, how the link was shared, the intended recipient, and the unintended recipient or audience.
• Ask the unintended recipient not to open, copy, or redistribute the link. Request confirmation of deletion when appropriate, without sending the URL again.
• Determine whether the paste is still available and whether its configured expiration has passed. Do not rely on expiration alone until you confirm the result through the relevant administrative or operational process.
• Notify the paste owner and the incident response contact.
• Assess the content for credentials, personal data, customer information, internal addresses, source code, or other confidential material.
• Rotate or revoke every credential that may have appeared in the paste, even if there is no evidence it was used.

Scenario 2: The URL appeared in a public place

• Capture limited evidence showing where and when the URL was exposed. Avoid placing the complete URL in additional systems, chat rooms, tickets, or screenshots unless access is tightly controlled.
• Request removal from the public location through the appropriate owner or platform process. Removal does not prove that nobody accessed or copied the content.
• Prioritize containment: expire or delete the paste if your deployment and operating procedure support that action, then rotate exposed secrets.
• Check available logs and monitoring for requests, unusual access, or related activity. Keep in mind that logging capabilities differ between hosted and self-hosted deployments.
• Assess whether the content includes regulated data, customer data, or information covered by a contract. Escalate to privacy, legal, compliance, or communications teams according to your incident plan.
• Preserve the relevant evidence in a restricted location before changing settings or deleting records that may be needed for investigation.

Scenario 3: The paste contained a credential or access token

• Identify the credential type, associated account or service, privileges, environments, and known expiration.
• Revoke or rotate the credential immediately through the authoritative identity, cloud, source-control, or service-management system.
• Look for use of the credential before and after the exposure window. Review authentication, API, cloud, repository, and endpoint logs where available.
• Check whether the same secret was reused elsewhere. Search approved secret-management records and deployment configuration, not public systems or unprotected local files.
• Notify affected system owners and document the exact time containment occurred.
• Do not paste replacement credentials into another paste. Use your organization’s password manager, secrets manager, or approved secure transfer workflow.

Scenario 4: The paste contained personal, health, payment, or customer data

• Identify the categories of data, individuals or customers affected, approximate volume, geographic scope, and retention period.
• Restrict access to the incident record and preserve a controlled copy of the relevant content if your investigation requires it.
• Ask the privacy or compliance owner to apply the organization’s data protection and notification assessment process.
• Check applicable contractual commitments, data processing terms, internal escalation deadlines, and regulatory requirements with qualified counsel or the responsible compliance team.
• Document decisions, including why notification was or was not considered necessary. Do not make a legal conclusion based solely on the paste platform’s encryption design.

Scenario 5: You cannot determine whether the link was accessed

• Record the uncertainty rather than treating it as proof of access or proof of no access.
• Use available service, web-server, reverse-proxy, identity, endpoint, and platform logs to establish the most reliable access timeline.
• Assume that a publicly reachable URL may have been copied, cached, or forwarded unless controls provide a defensible alternative conclusion.
• Complete the same content assessment and credential-rotation steps used for a confirmed exposure.

What to double-check

Paste state and deployment configuration

Confirm the paste’s expiration, deletion status, visibility settings, size or retention limits, and any access controls configured by the instance. Exact behavior can vary by version, hosting model, and configuration. If you operate the instance, review the relevant application settings, reverse-proxy rules, backups, and administrative records rather than assuming that deleting a browser tab deletes server-side data.

Review whether the URL was exposed in referrer data, browser history, chat previews, ticket exports, CI logs, analytics systems, backups, or screenshots. The incident is not necessarily closed when the original message is deleted.

Evidence and timeline

Create a concise timeline containing discovery, original exposure, paste creation if known, containment, secret rotation, access-log review, notifications, and closure approval. Preserve the minimum evidence needed for accountability. Store the complete URL and sensitive paste content only where the incident team has an approved need to access them.

Control and audit implications

Map the event to your existing incident response, access control, data retention, vendor risk, and secure communications procedures. For audit readiness, preserve evidence of who made decisions, which credentials were rotated, what logs were reviewed, and which corrective actions were assigned. The PrivateBin audit evidence checklist for ISO 27001 and SOC 2 can help organize related records.

If a hosted service is involved, document the service boundary, relevant responsibilities, and questions about logging, retention, deletion, and incident support. The PrivateBin security questionnaire guide provides a starting point for reviewing hosted and self-hosted deployments.

Common mistakes

• Forwarding the leaked URL to investigate. Use a restricted incident channel and avoid increasing distribution.
• Assuming expiration makes the incident harmless. Expiration limits future availability but does not undo copying, viewing, or downstream disclosure.
• Rotating only the obvious credential. Review tokens, passwords, private keys, signed URLs, database connection strings, and credentials embedded in logs.
• Deleting evidence before recording the facts. Preserve a controlled timeline and relevant logs before cleanup, while minimizing unnecessary copies of the data.
• Confusing encryption with access control. Client-side encryption can reduce server-side plaintext exposure, but a recipient with the complete usable link may still be able to read the paste.
• Ignoring secondary locations. Search tickets, chat, repositories, monitoring output, browser history, exports, and backups for the URL or pasted content.
• Declaring closure after the paste disappears. Confirm secret rotation, access review, notification decisions, evidence retention, and assigned corrective actions.
• Using PrivateBin for the wrong type of secret. For long-lived credentials, high-value keys, or managed machine-to-machine access, evaluate a secrets manager or password manager instead. The article on secure secret sharing for DevOps compares the workflow considerations.

When to revisit

Review this runbook before seasonal planning cycles, tabletop exercises, major deployment changes, and quarterly incident-response reviews. Revisit it whenever your PrivateBin version, hosting arrangement, retention configuration, logging pipeline, reverse proxy, authentication model, or approved sharing workflow changes.

After every real incident or near miss, update the checklist with the facts that slowed response: unclear ownership, missing logs, uncertain deletion behavior, delayed credential rotation, or an unapproved sharing channel. Test that responders know who can expire a paste, who owns credential revocation, who performs the privacy assessment, and where evidence is stored.

Keep a short operational version available to responders: contain the link, assess the content, rotate exposed secrets, preserve evidence, review access, escalate data-protection questions, and document lessons. Pair it with your broader incident response plan and your current deployment-specific documentation. Before the next exercise, verify each step against the actual PrivateBin configuration rather than relying on assumptions from a different instance or version.