PrivateBin

Release v2.0.3 - Fix arbitrary PHP file inclusion & self-XSS vulnerabilities

2025-11-12T08:15:00+01:00

This release addresses issues with arbitrary PHP file inclusion when enabling template switching and lacking sanitation of file names when drag-&-dropping files into PrivateBin with malicious filenames.

This has been mitigated in PrivateBin 2.0.3, so we strongly urge users to update.

More details of the vulnerabilties, mitigation etc. can be found in the vulnerability reports:

Template-switching feature allowing arbitrary local file inclusion through path traversal
Malicious filename can be used for self-XSS / HTML injection locally for users

Changes since v2.0.2

FIXED: Prevent arbitrary PHP file inclusion when enabling template switching
FIXED: Malicious filename can be used for self-XSS / HTML injection locally for users
FIXED: Unable to create a new paste from the cloned one when a JSON file attached (#1585)

Help wanted & greatly appreciated

Apart from the large tasks that require deeper insight and time, there are also smaller issues were help is wanted, topics open to debate and of course many languages that still remain to be translated. We are also still looking for additional long term maintainers among our frequent issue helpers.

What can we offer you in return for your help?

We can offer you our mentorship, if this is your first time participating as a maintainer of an open source software project. We can guide you through submitting your first pull requests and work with you to ensure your change fulfils the communities quality standards, gets merged and makes it into a release.
Your work gets publicly credited. This can help you build up a resume, showing off your growing skill set, in programming as well as your soft skills.
PrivateBin is a smaller project. If you'd like to learn how to participate and contribute in an open source git project, this should be less overwhelming than larger projects.
We do have a decent unit test code coverage, so it is an environment forgiving of mistakes. You may still introduce logical flaws or issues in new features, not yet covered in the tests, but you can rely on the tests preventing any regressions in other areas.
You don't have to be proficient in multiple programming languages, there are a lot of things to improve within either the JavaScript or PHP areas that don't need you to understand the other side, beyond their shared API.
It can be an opportunity to learn about continuous integration tools to automate tasks like tests, security scans, etc.

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools to get you started. For any questions, you can chat with the maintainers in the discussion area or reach us via email.

Vulnerability Report: Malicious filename can be used for self-XSS / HTML injection locally for users (CVE-2025-64711)

2025-11-12T08:15:00+01:00

Dragging a file whose filename contains HTML is reflected verbatim into the page via the drag-and-drop helper, so any user who drops a crafted file on PrivateBin will execute arbitrary JavaScript within their own session (self-XSS). This allows an attacker who can entice a victim to drag or otherwise attach such a file to exfiltrate plaintext, encryption keys, or stored pastes before they are encrypted or sent.

Note 1: as the malicious filename must contain the > character, the victim must not be using Windows for this to work, since this OS simply forbids this character in filenames.

Note 2: most PrivateBin instances use the Content-Security-Policy header to prevent most use-cases of this vulnerability. This report will describe the impact as if this header had been disabled by the PrivateBin instance owner.

Affected versions

PrivateBin versions since 1.7.7.

Conditions

Only macIOS or Linux users are affected, due to the way the > character is treated in a file name on Windows.
The PrivateBIn instance needs to have file upload enabled.
An attacker needs to have access to the local file system or somehow convince the user to create (or download) a malicious file (name).
An attacker needs to convince the user to attach that malicious file to PrivateBin.

Impact

Any Mac / Linux user who can be tricked into dragging a maliciously named file into the editor is impacted; code runs in the origin of the PrivateBin instance they are using. Attackers can steal plaintext, passphrases, or manipulate the UI before data is encrypted, defeating the zero-knowledge guarantees for that victim session, assuming counter-measures like Content-Security-Policy (CSP) have been disabled.

If CSP is not disabled, similar HTML injection attacks as described in CVE-2025-62796 may be possible - like redirecting to a foreign website, phishing etc.

Real-life impact

As the whole exploit needs to be included in the file name of the attached file and only affects the local session of the user (aka it is neither persistent nor remotely executable) and that user needs to interact and actively attach that file to the paste, the impact is considered to be practically low.

Technical Description

When a file is dropped, readFileData collects all filenames and calls printDragAndDropFileNames:

const fileNames = loadedFiles.map((loadedFile => loadedFile.name));
printDragAndDropFileNames(fileNames);

printDragAndDropFileNames then renders those names:

        function printDragAndDropFileNames(fileNames) {
            $dragAndDropFileNames.html(fileNames.join('<br>'));
        }

This will insecurely render the user-submitted filenames as HTML.

This vulnerability has been introduced in this commit (introduced in 1.7.7).

The previous render method was using .text():

$dragAndDropFileName.text(loadedFile.name);

Reproduction Steps

On a Unix-like system, create a file with an HTML/JS payload in its name, e.g. by running touch '"><img src=x onerror=alert(document.domain)>.txt'.
Deploy or use any PrivateBin instance with attachments enabled (including https://privatebin.net/).
Open the UI in a browser and start a new paste.
Drag the crafted file anywhere on the page
As soon as it is dropped, the filename is inserted into #dragAndDropFileName as HTML and the onerror handler fires (assuming CSP is disabled), showing the alert.

Mitigation

We strongly recommend you to upgrade to our latest release. However, here are some workarounds that may help you to mitigate this vulnerability without upgrade:

Update the CSP in your configuration file to the latest recommended settings and check that it isn't getting reverted or overwritten by your web server, reverse proxy or CDN, i.e. using our offered check service. Note: You should check your CSP independently, even if you upgrade to a fixed version.
Deploying PrivateBin on a separate domain may limit the scope of the vulnerability to PrivateBin itself and thus, as described in the “Impact” section, effectively prevent any damage by the vulnerability to other resources you are hosting.
As explained in the impact assessment, disabling attachments also prevents this issue.

Patches

The issue has been patched in version 2.0.3.

Credits

We'd like to thank Benoit Esnard, who reported this vulnerability.

In general, we'd like to thank everyone reporting issues and potential vulnerabilities to us.

If you think you have found a vulnerability or potential security risk, we'd kindly ask you to follow our security policy and report it to us. We then assess the report and will take the actions we deem necessary to address it.

Timeline

2025-11-09 Received report via GitHub Security Advisory
2025-11-10 Discussed and reproduced issue, created a patch
2025-11-11 Further work on patch
2025-11-12 Released patch with PrivateBin 2.0.3

Vulnerability Report: Template-switching feature allowing arbitrary local file inclusion through path traversal (CVE-2025-64714)

2025-11-12T08:15:00+01:00

An unauthenticated Local File Inclusion exists in the template-switching feature: if templateselection is enabled in the configuration, the server trusts the template cookie and includes the referenced PHP file. An attacker can read sensitive data or, if they manage to drop a PHP file elsewhere, gain RCE.

Affected versions

PrivateBin versions since 1.7.7.

Conditions

templateselection got enabled in cfg/conf.php
Visitor sets a cookie template pointing to an existing PHP file without it's suffix, using a path relative to the tpl folder. Absolute paths do not work.

Impact

The constructed path of the template file is checked for existence, then included. For PrivateBin project files this does not leak any secrets due to data files being created with PHP code that prevents execution, but if a configuration file without that line got created or the visitor figures out the relative path to a PHP script that directly performs an action without appropriate privilege checking, those might execute or leak information.

Impact analysis

In detail, we have analyzed different ways of exploiting this vulnerability and found no way to cause a full remote code execution (RCE) vulnerability or denial of service (DoS) as recursive includes, e.g., are not possible.

Generally, it is again notably to remember only PHP files of the local filesystem can be included. That's why we have analyzed PrivateBin's PHP files, that may be an attack target.

the PrivateBin config file is by default protected as it prevents access itself resulting in a 403 HTTP status code. We further call this the “(PHP) protection line”.
Likewise, the paste data cannot be accessed due to that “protection line”. Each created file contains the same line protecting it against PHP execution/inclusion.
As for the salt, purge_ and traffic_limiter files, they get included, but no data is displayed (variables or comments only), and a webserver specific error message is returned.
When one tries to include index.php, you get a PHP error (possibly visible, depending on the webserver setup), due to define being called twice.
With any of the files in lib and likely those in vendor (we have not verified each dependency), code is only declared and not executed and the result is again a webserver specific error message.
With the scripts in bin, the result is an error message, but code is executed to some extent, but you cannot pass arguments to any administrative scripts as they are read via $_SERVER['argc'].

That said, the vulnerability could be used to chain more attacks or execute other non-PrivateBin related PHP files on the host system, if such other files exist and the (relative) path to them can be guessed. Also, should for some reason the PHP “protection line” be missing on your deployment the impact could be much worse and e.g. data like the URL shortener token or the database configuration from the configuration file could possibly be exfiltrated.

Real-life impact

We checked all instances versioned 1.7.7 and above listed in the PrivateBin directory and did find 11 instances that had the template switcher enabled. We used the following script to detect this:

for URL in $(
    curl --silent --header 'Accept: application/json' 'https://privatebin.info/directory/api?top=100&version=1.7.7' | jq --raw-output '.[].url'
) $(
    curl --silent --header 'Accept: application/json' 'https://privatebin.info/directory/api?top=100&version=1.7.8' | jq --raw-output '.[].url'
) $(
    curl --silent --header 'Accept: application/json' 'https://privatebin.info/directory/api?top=100&version=2'     | jq --raw-output '.[].url'
)
do
    curl --silent "$URL" | grep -q 'id="template"' && echo "$URL uses template switcher"
done

None of these instances had an unprotected PrivateBin configuration file in use. We used the following script, that may be adapted to check any single instance:

curl --silent --cookie  'template=../cfg/conf' https://privatebin.net

Technical Description

Users can select their preferred template via the template cookie, as seen in TemplateSwitcher::getSelectedByUserTemplate:

    private static function getSelectedByUserTemplate(): ?string
    {
        $selectedTemplate    = null;
        $templateCookieValue = $_COOKIE['template'] ?? '';

        if (self::isTemplateAvailable($templateCookieValue)) {
            $selectedTemplate = $templateCookieValue;
        }

        return $selectedTemplate;
    }

In this commit, introduced in 1.7.7, the TemplateSwitcher::isTemplateAvailable method went from this:

    public static function isTemplateAvailable(string $template): bool
    {
        return in_array($template, self::getAvailableTemplates());
    }

to this:

    public static function isTemplateAvailable(string $template): bool
    {
        $available = in_array($template, self::getAvailableTemplates());

        if (!$available && !View::isBootstrapTemplate($template)) {
            $path      = View::getTemplateFilePath($template);
            $available = file_exists($path);
        }

        return $available;
    }

The new code will now blindly trust $template, unless it starts with the string bootstrap-.

View::getTemplateFilePath will return PATH . 'tpl' . DIRECTORY_SEPARATOR . $file . '.php', allowing directory traversal, but preventing non-PHP files to be included.

View::draw will then include the user-submitted template:

    public function draw($template)
    {
        $path = self::getTemplateFilePath($template);
        if (!file_exists($path)) {
            throw new Exception('Template ' . $template . ' not found!', 80);
        }
        extract($this->_variables);
        include $path;
    }

Note: this is only possible if templateselection configuration is enabled, or if no template has been set. The template will be rewritten if this condition isn't met:

    private function _setDefaultTemplate()
    {
        $templates = $this->_conf->getKey('availabletemplates');
        $template  = $this->_conf->getKey('template');
        TemplateSwitcher::setAvailableTemplates($templates);
        TemplateSwitcher::setTemplateFallback($template);

        // force default template, if template selection is disabled and a default is set
        if (!$this->_conf->getKey('templateselection') && !empty($template)) {
            $_COOKIE['template'] = $template;
            setcookie('template', $template, array('SameSite' => 'Lax', 'Secure' => true));
        }
    }

Reproduction Steps

Configure PrivateBin with templateselection = true (default template list is fine).
Send a request with a malicious template cookie like template=../cfg/conf, where the relative path points to a PHP file without its file suffix
The script now includes the select PHP file (leading to a 500 in that specific case).

Mitigation

Patches

The issue has been patched in version 2.0.3.

Workarounds

Set templateselection = false in cfg/conf.php or remove it, it's default is false.

Credits

We'd like to thank Benoit Esnard, who reported this vulnerability.

In general, we'd like to thank everyone reporting issues and potential vulnerabilities to us.

Timeline

2025-11-09 Received report via GitHub Security Advisory
2025-11-10 Discussed and reproduced issue, wrote a unit test case based on this, started work on a patch
2025-11-11 Further work on patch, refactored related code
2025-11-12 Released patch with PrivateBin 2.0.3

Vulnerability Report: Missing HTML sanitisation of attached filename in file size hint enabling persistent XSS, defacement, open redirect attacks etc. (CVE-2025-62796)

2025-10-28T17:00:00+01:00

We've identified an HTML injection/XSS vulnerability in the PrivateBin service that allows the injection of arbitrary HTML markup via the attached filename. Below are the technical details, PoC, reproduction steps, impact, and mitigation recommendations.

Recommend action: As the vulnerability has been fixed in the latest version, users are strongly encouraged to upgrade PrivateBin to the latest version and check that a strong CSP header, just as the default suggested one, is delivered.

Summary of the vulnerability: The attachment_name field containing the attached file name is included in the object that the client encrypts and is eventually rendered in the DOM without proper escaping.

Impact

The vulnerability allows attackers to inject arbitrary HTML into the filename displayed near the file size hint, when attachments are enabled. This is by definition a XSS vulnerability (CWE-80), in this case even a persistent XSS. As any HTML can be injected, basically, this can e.g. be used to inject a script tag (as per CWE-79).

That said, also due to previous issues, we have strong mitigations for this in place. The content security policy (CSP) does, if configured as recommend by the PrivateBin project, prevent any inline script execution, so the confidentiality of the paste is not affected.

However, as the reporter demonstrated, even when script execution is blocked, an HTML injection can still be used for attacks such as:

redirection using a meta redirect tag to redirect to a potentially malicious/attacker-controlled website
defacement of the website
phishing, in combination with the redirection to a clone of a PrivateBin phishing page or similar
potential attacks on other services hosted on the same domain

This list is by no means meant to be exhaustive, other attacks should be considered possible, that is why we treat this issue as a serious issue, even if the CSP is supposed to block the most attacks.

Important

Depending on the deployment, if the server has a different than the recommend CSP configured or the client (browser) somehow lacks a protection, the vulnerability can have much more serious impacts and potentially also allow XSS, which could mean the confidentiality of the PrivateBin instance is affected.

Technical Description

The front-end uses PrivateBin (client-side encryption) to format and encrypt data before sending. During the paste creation process, the client assembles a cipherMessage object containing, among other fields:

paste -> paste text
attachment -> file content (data-URI)
attachment_name -> array with file names

Before encryption, the ServerInteraction.setCipherMessage(cipherMessage) function is called. By intercepting/altering the cipherMessage on the client immediately before encryption, it is possible to replace attachment_name with an attacker-controlled string; this string becomes part of the encrypted content, and when the paste is opened, the local client decrypts and inserts the name into the DOM unescaped, allowing the interpretation of inserted HTML markup.

Note that it was not necessary to reimplement encryption: the monkeypatch modifies the object before the client applies AES-GCM/PBKDF2/compression, thus avoiding ciphertext formatting issues.

Proof of Concept

Paste this into the console on the PrivateBin page before clicking Create.

// Monkeypatch to modify attachment_name immediately before encryption
(() => {
  const desiredName = '"><meta http-equiv="refresh" content="0;url=https://example.com/">.txt'; // <- adjust here

  // get the namespace used by PrivateBin
  if (!window.$ || !$.PrivateBin || !$.PrivateBin.ServerInteraction) {
    return console.error('PrivateBin namespace not found (make sure you are on the PrivateBin page).');
  }

  const SI = $.PrivateBin.ServerInteraction;
  // save original function
  const origSetCipherMessage = SI.setCipherMessage?.bind(SI);

  if (typeof origSetCipherMessage !== 'function') {
    return console.error('setCipherMessage not found or is not a function.');
  }

  SI.setCipherMessage = async function(cipherMessage) {
    try {
      // cipherMessage here is the plain object the client intends to encrypt
      if (cipherMessage && Array.isArray(cipherMessage.attachment_name)) {
        console.log('[patch] original attachment_name:', cipherMessage.attachment_name);
        cipherMessage.attachment_name = cipherMessage.attachment_name.map(() => desiredName);
        console.log('[patch] attachment_name overwritten to:', cipherMessage.attachment_name);
      } else if (cipherMessage && cipherMessage.attachment && Array.isArray(cipherMessage.attachment)) {
        // if there are attachments but no attachment_name (rare), add a coherent array
        cipherMessage.attachment_name = cipherMessage.attachment.map(() => desiredName);
        console.log('[patch] attachment_name added:', cipherMessage.attachment_name);
      } else {
        // nothing to change
      }

      // call the original implementation (which performs the encryption)
      return await origSetCipherMessage(cipherMessage);
    } catch (err) {
      console.error('Error in setCipherMessage monkeypatch:', err);
      // in case of error, attempt to call the original anyway
      return await origSetCipherMessage(cipherMessage);
    }
  };

  console.log('Monkeypatch applied to ServerInteraction.setCipherMessage() - ready to send. (Reload the page to undo).');
})();

Reproduction Steps

Access PrivateBin (in the program scope). A requirement is that you have file upload enabled.
Attach any file via the UI (file content irrelevant).
Open the browser console (F12 → Console).
Paste the snippet above and adjust desiredName to the desired HTML payload (e.g., "><meta http-equiv="refresh" content="0;url=https://example.com/">.txt).
Click Create. The client will encrypt and send the paste normally.
Intercept/inspect the POST request (optional).
Open the generated link.

What happens: When rendering the paste, the content of the injected attachment_name will be interpreted according to the context, demonstrating the impact.

Mitigation

We strongly recommend you to upgrade to our latest release. However, here are some workarounds that may help you to mitigate this vulnerability without upgrade:

Update the CSP in your configuration file to the latest recommended settings and check that it isn't getting reverted or overwritten by your web server, reverse proxy or CDN, i.e. using our offered check service.
Note: You should check your CSP independently, even if you upgrade to a fixed version. See also the section "More information" about how we recently enhanced the CSP protection.
Deploying PrivateBin on a separate domain may limit the scope of the vulnerability to PrivateBin itself and thus, as described in the "Impact" section, effectively prevent any damage by the vulnerability to other resources you are hosting.
As explained in the impact assessment, disabling attachments also prevents this issue.

Patches

The issue has been patched in version 2.0.2. The change that displayed the attachment name without sanitation was introduced in version 1.7.7. The code-changes in PrivateBin mitigating this issue can be found in commit c4f8482b3072be7ae012cace1b3f5658dcc3b42e.

References

We highly encourage server administrators and others involved with the PrivateBin project to read-up on how Content-Security-Policies work, especially should you consider to manually adjust it:

Also please note that if multiple headers are set (as e.g. done via our introduced meta tag) browsers should apply the most restrictive set of the policies, as per the CSP specification.

More information

This issue is similar to GHSA-cqcc-mm6x-vmvw, but was, based on our analysis, apparently introduced in #1550.

Note that we have, independently as of this issue and as per regular security maintenance, already applied many CSP improvements and strengthened this security mechanism of PrivateBin. This includes in detail:

As part of the last XSS vulnerability, we have now included the CSP in a meta HTML tag, too, so in case the headers are somehow mangled with by (reverse) proxies or similar, the PrivateBin instance should still be protected as long as this HTML meta tag is included in an unchanged way.
#1613 - We have removed a outdated configuration recommendation, as default-src does not need to allow self anymore, but it can keep the more strict none even when using the bootstrap SVG icons. (previously a problem in Firefox prevented this)
#1464 - We could remove the previously used unsafe-eval that was a potentially risky CSP source being allowed for scripts, and replaced it with wasm-unsafe-eval for the streaming of a WebAssembly component used for optional compression. This can be disabled in the configuration and then wasm-unsafe-eval can also be removed.

In case you have not noticed this and did not upgrade your CSP header yet, we strongly recommend to do it as soon as possible!

Credits

On Thursday October 23rd, 2025 we received a report via email at security@privatebin.org. The reporter asked to stay anonymous. We thank them a lot for the detailed reporting of this vulnerability, including the description of the proof of concept listed above!

In general, we'd like to thank everyone reporting issues and potential vulnerabilities to us.

Timeline

2025-10-23 Received report via email
2025-10-23 Acknowledged report to sender
2025-10-24 Discussed and reproduced issue, wrote a unit test case based on this
2025-10-25 Worked on a patch as well as discussing other potentially problematic spots and applying similar sanitation to those.
2025-10-28 Released patch with PrivateBin 2.0.2

Release v2.0.2 - Fix HTML injection/XSS vulnerability in filenames of attached files (CVE-2025-62796)

2025-10-28T10:00:00+01:00

This release fixes a security vulnerability that allowed HTML injection/XSS (CVE-2025-62796.

This has been mitigated in PrivateBin 2.0.2, so we strongly urge users to update.

More details of the vulnerability, mitigation etc. can be found in the vulnerability report.

Changes since v2.0.1

CHANGED: Upgrading libraries to: DOMpurify 3.3.0
CHANGED: Refactored jQuery DOM element creation into plain JavaScript
FIXED: Sanitize file name in attachment size hint (CVE-2025-62796 / https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-867c-p784-5q6g)
FIXED: PHP OPcache module is optional again (#1679)
FIXED: bootstrap template password peek input group display

Help wanted & greatly appreciated

What can we offer you in return for your help?

We can offer you our mentorship, if this is your first time participating as a maintainer of an open source software project. We can guide you through submitting your first pull requests and work with you to ensure your change fulfils the communities quality standards, gets merged and makes it into a release.
Your work gets publicly credited. This can help you build up a resume, showing off your growing skill set, in programming as well as your soft skills.
PrivateBin is a smaller project. If you'd like to learn how to participate and contribute in an open source git project, this should be less overwhelming than larger projects.
We do have a decent unit test code coverage, so it is an environment forgiving of mistakes. You may still introduce logical flaws or issues in new features, not yet covered in the tests, but you can rely on the tests preventing any regressions in other areas.
You don't have to be proficient in multiple programming languages, there are a lot of things to improve within either the JavaScript or PHP areas that don't need you to understand the other side, beyond their shared API.
It can be an opportunity to learn about continuous integration tools to automate tasks like tests, security scans, etc.

Release v2.0.0 - Changes configuration defaults & template

2025-07-28T10:00:00+02:00

This release changes configuration defaults including switching the template and removing legacy features.

The most notable change is the switch of the default template to bootstrap5. We switched to use the Jdenticons library by default for the comment creator icons, as it doesn't require the GD library. And we changed the user interface to display SI-prefixes instead of binary bytes for data sizes, to be more consistent with sizes displayed in current operating systems, i.e. 1024 bytes now will be displayed as 1.02 kB instead of 1.00 kiB and refer to "documents" instead of "pastes".

The page template and compatibility to pre-v1.3 pastes, including ZeroBin ones, got removed. The v2 paste format which is still currently used, got introduced in release 1.3 in July 2019. This allows dropping further unused database columns, as those were artifacts of the v1 pastes and not used anymore with the v2 ones.

Update procedure

The minimum required PHP version was increased from 7.3 to 7.4.

If you have created your own cfg/conf.php file, please check the following entries and update them accordingly:

section [main], key template: If set to page replace this with bootstrap5 or one of the bootstrap variants (see cfg/conf.sample.php).
section [main], key icon: If commented and you prefer the look of the blocky identicon over triangular jdenticon, uncomment the value and set it back to identicon.
section [model], key class: If set to privatebin_data replace this with Filesystem and if set to privatebin_db or zerobin_db replace this with Database.

If you are using the Database model class and your database user is not privileged to perform schema changes, you have to manually drop the postdate, opendiscussion, burnafterreading, attachment and attachmentname columns of the paste table and the nickname column from the comment table. If you are using SQLite before 3.35.0, which doesn't support dropping columns, you must initialize a new empty database file and either manually migrate the data or start from scratch.

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a container images using the nginx web server with php-fpm and one using the nginx unit application server, that include the recommended secure setup with the non-essential files and data outside of the web servers document root.

Optionally, you can use the bin/administration scripts' two new features to check if any v1 pastes still exist on your instance using the --statistics flag and then delete them using the --delete-v1 flag:

$ bin/administration --help
Usage:
  administration [--delete <document id> | --delete-all | --delete-v1 |
                  --empty-dirs | --help | --list-ids | --purge | --statistics]

Options:
[...]
  --delete-v1       deletes all unsupported v1 documents
[...]
  -s, --statistics  reads all stored documents and reports statistics
$ bin/administration --statistics
[... check for lines starting with "Unsupported v1 document " and the conclusion showing any "Legacy v1" ...]
$ bin/administration --delete-v1

Changes since version 1.7.8

ADDED: Error logging in database and filesystem backend (#1554)
ADDED: Statistics on v1 pastes in administration script and option to delete them
CHANGED: Removed page template (#265)
CHANGED: Removed support for ZeroBin & v1 pastes - since release 1.3 the v2 format is used (#551)
CHANGED: Removed use of base64 & rawinflate libraries (#551)
CHANGED: Removed support for privatebin_data, privatebin_db & zerobin_db model class configurations, must be replaced with Filesystem or Database in cfg/conf.php, if still present
CHANGED: Removed unused columns in database schema of tables paste & comment
CHANGED: Jdenticons are now used as the default icons
CHANGED: Upgrading libraries to: base-x 5.0.1, bootstrap 5.3.7, jdenticon 2.0.0 & kjua 0.10.0
CHANGED: Minimum required PHP version is 7.4, due to a change in the jdenticon library
CHANGED: Set bootstrap5 template as default for PrivateBin (#1572)
CHANGED: Switched from binary bytes to SI-units (#1565)
CHANGED: Replaced the term "paste" with the more generic "document" (#397)
FIXED: Name mismatches in attached files (#1584)
FIXED: Unable to paste attachments from clipboard (#1589)
FIXED: Configuration combinations test errors

Changes since version 1.7.7

FIXED: Duplicate attachment for every comment (#1577)
FIXED: Attachments with empty file names (#1577)
FIXED: Page template scripts loading order (#1579)

Changes since version 1.7.6

ADDED: Switching templates using the web ui (#1501)
ADDED: Show file name and size on download page (#603)
CHANGED: Passing large data structures by reference to reduce memory consumption (#858)
CHANGED: Removed use of ctype functions and polyfill library for ctype
CHANGED: Upgrading libraries to: DOMpurify 3.2.6, ip-lib 1.20.0
CHANGED: Support for multiple file uploads (#1060)
CHANGED: Documented CSP change necessary to allow PDF attachment preview (#1552)
FIXED: Hide Reply button in the discussions once clicked to avoid losing the text input (#1508)
FIXED: Bump zlib library suffix, ensuring cache refresh for WASM streaming change
FIXED: Handle undefined globals in file based persisted values (#1544)

Changes since version 1.7.5

ADDED: Ability to copy the paste by clicking the copy icon button or using the keyboard shortcut ctrl+c/cmd+c (#1390 & #12)
CHANGED: Allow toggling tab-key-support using [Ctrl]+[m] or [Esc] in textarea for keyboard navigation (#1386)
CHANGED: Switched to WASM streaming and replace unsafe-eval with wasm-unsafe-eval CSP declaration (#1464), requires webserver to have application/wasm MIME type configured.
CHANGED: Replaced usage of strpos with str_starts_with & str_contains (#1373)
CHANGED: Added polyfill libraries for ctype, str_starts_with & str_contains functions (#1476)
CHANGED: Turned paste delete link into a button (#266)
CHANGED: Upgrading libraries to: DOMpurify 3.2.4, cloud-storage 1.45.0, aws-sdk-php 3.336.2
CHANGED: bootstrap5 template UI improvements
FIXED: Redirect to the home page after changing the language (#92)

Changes since version 1.7.4

ADDED: Allow non persistent SQL connections, if configured (#1394)
ADDED: Show a button (that redirects to the basepath URL) inside the alert after a paste is deleted
CHANGED: Tweaked page footer of the bootstrap5 template (#1392)
CHANGED: Simpler PostgreSQL table lookup query (#1361)
CHANGED: SRI hashes are now configurable, no longer hardcoded in templates (#1365)
CHANGED: Upgrading libraries to: DOMpurify 3.1.7, ip-lib 1.18.1, cloud-storage 1.43.0, aws-sdk-php 3.325.0
FIXED: Numeric array keys being cast to integer causing failures under strict type checking (#1435)

Changes since version 1.7.3

CHANGED: Saving markdown pastes uses .md extension instead of .txt (#1293)
CHANGED: Enable strict type checking in PHP (#1350)
CHANGED: Various tweaks of the bootstrap5 template, suggested by the community
FIXED: Reset password input field on creation of new paste (#1194)
FIXED: Allow database schema upgrade to skip versions (#1343)
FIXED: bootstrap5 dark mode toggle unset on dark browser preference (#1340)
FIXED: Prevent bypassing YOURLS proxy URL filter, allowing to shorten non-self URLs

Changes since version 1.7.2

CHANGED: Various tweaks of the bootstrap5 template, suggested by the community
CHANGED: Upgrading libraries to: DOMpurify 3.1.3
FIXED: Selected expiration not being applied, when using bootstrap template (#1309)

Changes since version 1.7.1

ADDED: Allow use of shortenviayourls in query parameters (#1267)
ADDED: Input sanitation to some not yet filtered query and server parameters
ADDED: Optional Bootstrap CSS 5.3.3 based template, use configuration template = "bootstrap5" to switch to it (#728)
CHANGED: "Send" button now labeled "Create" (#946)
CHANGED: Drop some PHP < 5.6 fallbacks, minimum version is PHP 7.3 as of release 1.6.0
CHANGED: Set lang cookie with lax SameSite property
CHANGED: Upgrading libraries to: DOMpurify 3.1.2 (#1299) & jQuery 3.7.1
CHANGED: create attribute is no longer returned in API for pastes & can be disabled for comments using discussiondatedisplay as well (#1290)
FIXED: Add cache control headers also to API calls (#1263)
FIXED: Shortened paste URL does not appear in email (#606)

Changes since version 1.7.0

FIXED: zlib 1.3.1 wasm file reference

Help wanted & greatly appreciated

What can we offer you in return for your help?

We can offer you our mentorship, if this is your first time participating as a maintainer of an open source software project. We can guide you through submitting your first pull requests and work with you to ensure your change fulfils the communities quality standards, gets merged and makes it into a release.
Your work gets publicly credited. This can help you build up a resume, showing off your growing skill set, in programming as well as your soft skills.
PrivateBin is a smaller project. If you'd like to learn how to participate and contribute in an open source git project, this should be less overwhelming than larger projects.
We do have a decent unit test code coverage, so it is an environment forgiving of mistakes. You may still introduce logical flaws or issues in new features, not yet covered in the tests, but you can rely on the tests preventing any regressions in other areas.
You don't have to be proficient in multiple programming languages, there are a lot of things to improve within either the JavaScript or PHP areas that don't need you to understand the other side, beyond their shared API.
It can be an opportunity to learn about continuous integration tools to automate tasks like tests, security scans, etc.

Vulnerability Report: Bypass of YOURLS proxy URL filter allows shortening URLs via YOURLs for other domains rather than the PrivateBin instance

2024-07-09T21:00:00+02:00

In v1.5 we introduced the YOURLS server-side proxy. The idea was to allow using the YOURLs URL shortener without running the YOURLs instance without authentication and/or exposing the authentication token to the public, allowing anyone to shorten any URL. With the proxy mechanism, anyone can shorten any URL pointing to the configured PrivateBin instance. The vulnerability allowed other URLs to be shortened, as long as they contain the PrivateBin instance, defeating the limit imposed by the proxy.

Neither the confidentially of existing pastes on the server nor the configuration options including the YOURLs token are affected.

Impact

This issue only affects non-standard configurations of PrivateBin. Instances are affected if all of the following conditions are met: 1. The PrivateBin instance enables URL shortening. 2. A YOURLs URL shortener is used and it is configured not to be public and require authentication to shorten URLs. 3. A basepath, the YOURLs proxy mechanism and an authentication token is configured in PrivateBin to use the non-public YOURLs instance. 4. A crafted URL is sent to PrivateBins' YOURLs proxy endpoint with a URL that contains the PrivateBin instance URL as a GET-parameter or as part of the URL-fragment, but doesn't start with the instance URL (a third-party URL)

The root cause is, that the guard clause checking whether the URL to be shortened belongs to your own PrivateBin domain only checks if the PrivateBin instance is contained in the URL but not if it starts with it.

This is a kind of authentication bypass due to incomplete filtering. This has a similar impact like an open redirect except it does not directly redirect, but allows a further hiding of the target URL as is common and known for URL shorteners. If the URL shortener domain used is trusted by it's users, this allows hiding a malicious URL.

The highest impact may be that this can be used for phishing campaigns, by routing users to some kind of fake site mimicking the trusted shortener or PrivateBin domain, which could then extract sensitive data from entered data or similar. That said, this is a general concern with URL shorteners and users are advised to follow general phishing prevention attempts like verifying the domain of the site they are using and using a trusted PrivateBin instance.

Indicators of exploitation

Check your YOURLs proxy for shortened domains that do not start with your own PrivateBin instance. Also note, that for this to be a result of an exploitation of this vulnerability, somewhere in the URL the base path + ? e.g. https://privatebin.example/? has to appear in the destination URL, as this is what the guard checked for.

Patches

The problem has been patched in version 1.7.4 of PrivateBin. In addition to upgrading, users of the YOURLs proxy feature should check for the indicators of exploitation, as outlined above.

Workarounds

Disable URL shortening, if you have been using it.
Only the YOURLs proxy is affected. Other URL shortening options either require a public, un-authenticated shortener, or expose the token to the client, which by design allows shortening any URL.

Proof of concept

See the unit test that got introduced to prevent similar regressions for an example of a URL that would circumvent the configured basepath.

Here is an example of how a manual exploitation would work:

In a PrivateBin instance hosted on https://privatebin.example/, with a valid URL YOURLs shortening proxy configuration using a token to prevent un-authenticated short-URL creation, send a URL shortening request for the domain https://attacker.example.com/?q=https://privatebin.example/?foo#bar. attacker.example.com is any attacker controlled, arbitrary domain.

You can do this by sending a GET request to https://privatebin.example/shortenviayourls?link=https%3A%2F%2Fattacker.example.com%2F%3Fq%3Dhttps%3A%2F%2Fprivatebin.example%2F%3Ffoo%23bar, without URL encoding this looks as follows: https://privatebin.example/shortenviayourls?link=https://attacker.example.com/?q=https://privatebin.example/?foo#bar.

On an affected setup, you will get a valid short URL, which when accessed, leads to https://attacker.example.com/?foo#bar, the attackers domain. On a patched system your request will get rejected and only URLs starting with https://privatebin.example/?[...] are allowed for shortening.

Post-mortem

From our limited analysis, the issue has been introduced in commit 0dc9ab7 while refactoring. The use of substr got replaced by strpos. The initial contribution contained no tests, but an implementation without this flaw. All these changes got introduced in a single pull request. This follows many best practices, as tests were added and the refactoring was done in close collaboration with the original author.

In the future, we plan to switch to the more obvious, readable and understandable str_starts_with, which is available since PHP v8. Such a better function naming and insisting on using modern functions would not only result in a better code quality, but would possibly have prevented the issue, but for backwards-compatibility with PHP 7.3, we stay on the old function for now.

Final Thoughts

The project maintainers have always discouraged the use of URL shorteners and users are always safer sharing the complete, long URL to a paste, see our FAQ.

If you need or want to provide a URL shortener option as a PrivateBin instance administrator, YOURLs is the best option available to use with PrivateBin, because it is the only shortener supported, through the proxy mechanism, preventing arbitrarily shortening any URLs. Running a public URL shortener instance and allowing anonymous users shortening arbitrary domains invites the shortener getting abused.

References

PR to fix the vulnerability: https://github.com/PrivateBin/PrivateBin/pull/1370

Timeline

2024-06-28 Issue report by @nbxiglk via email
2024-06-29 Vulnerability reproduced by @elrido, mitigation created and shared with maintainers and issue reporter for review
2024-07-06 Pull request with mitigation raised

Release v1.7.0 - Ask for confirmation, before loading burn after reading pastes

2024-02-11T14:52:00+01:00

This release asks for confirmation, before loading burn after reading pastes.

In addition the new translations for the Romanian language got added, detection for damaged pastes during purge got introduced and a few minor user interface glitches resolved.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

Changes since version 1.6.2

ADDED: Translations for Romanian
ADDED: Detect and report on damaged pastes (#1218)
CHANGED: Ask for confirmation, before loading burn after reading pastes (#1237)
CHANGED: Focus on password input in modal dialog
CHANGED: Upgrading libraries to: DOMpurify 3.0.8 & zlib 1.3.1
FIXED: Support more types of valid URLs for shorteners, incl. IDN ones (#1224)
FIXED: Email timezone buttons overlapping in some languages (#1039)
FIXED: Changing language mangles URL (#1191)
FIXED: Needless reload when visiting default URL

Changes since version 1.6.1

FIXED: English not selectable when languageselection enabled (#1208)
FIXED: SRI mismatch due to cached file having changed (#1207)

Changes since version 1.6.0

ADDED: Right-To-Left (RTL) support for Arabic & Hebrew (#1174)
CHANGED: Upgrading libraries to: DOMpurify 3.0.6

Help wanted & greatly appreciated

What can we offer you in return for your help?

We can offer you our mentorship, if this is your first time participating as a maintainer of an open source software project. We can guide you through submitting your first pull requests and work with you to ensure your change fulfils the communities quality standards, gets merged and makes it into a release.
Your work gets publicly credited. This can help you build up a resume, showing off your growing skill set, in programming as well as your soft skills.
PrivateBin is a smaller project. If you'd like to learn how to participate and contribute in an open source git project, this should be less overwhelming then larger projects.
We do have a decent unit test code coverage, so it is an environment forgiving of mistakes. You may still introduce logical flaws or issues in new features, not yet covered in the tests, but you can rely on the tests preventing any regressions in other areas.
You don't have to be proficient in multiple programming languages, there are a lot of things to improve within either the JavaScript or PHP areas that don't need you to understand the other side, beyond their shared API.
It can be an opportunity to learn about continuous integration tools to automate tasks like tests, security scans, etc.

Release v1.6.0 - Adding new translations and dropping support for PHP < 7.3

2023-09-11T20:15:00+02:00

This release adds translations for Japanese & Arabic and increases the minimal required PHP version to 7.3.

In addition to the two new translations for the Japanese & Arabic languages, the Email-button is now a configurable option, but still enabled by default.

The minimum supported PHP version is now 7.3, due to having upgraded the PHP unit test framework which no longer supports older PHP releases. This simplifies our development (we no longer need to maintain a parallel branch that ensured PHP 8 compatibility) and let us drop a library that provided a more cryptographically secure random function to PHP 5.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

Changes since version 1.5.2

ADDED: Translations for Japanese & Arabic
ADDED: Configuration option to disable Email button (#1164)
CHANGED: Minimum required PHP version is 7.3, due to upgrading PHPunit (#707)
CHANGED: Removed PHP 5 polyfill for random_bytes()

Help wanted & greatly appreciated

What can we offer you in return for your help?

We can offer you our mentorship, if this is your first time participating as a maintainer of an open source software project. We can guide you through submitting your first pull requests and work with you to ensure your change fulfils the communities quality standards, gets merged and makes it into a release.
Your work gets publicly credited. This can help you build up a resume, showing off your growing skill set, in programming as well as your soft skills.
PrivateBin is a smaller project. If you'd like to learn how to participate and contribute in an open source git project, this should be less overwhelming then larger projects.
We do have a decent unit test code coverage, so it is an environment forgiving of mistakes. You may still introduce logical flaws or issues in new features, not yet covered in the tests, but you can rely on the tests preventing any regressions in other areas.
You don't have to be proficient in multiple programming languages, there are a lot of things to improve within either the JavaScript or PHP areas that don't need you to understand the other side, beyond their shared API.
It can be an opportunity to learn about continuous integration tools to automate tasks like tests, security scans, etc.

Release v1.5.2 - S3 storage improvements & library updates

2023-07-09T09:30:00+02:00

This release contains an improvement for the S3 storage & updates several libraries.

This patch release allows the AWS SDK to use default credential provider chain when using the S3 storage backend, exposes the used JSON-LD types in the API, addresses PHP 8.2 deprecation warnings and includes several updated libraries, including some security fixes.

When using the S3 storage backend, you now have the option of passing the S3 credential configuration in other ways than just the PrivateBin configuration file. If the credentials are not set in configuration, the AWS SDK will use the default credentials provider chain, which will look for credentials in a few places automatically, including environment variables or instance roles. For details on these, see the SDK's documentation on the default credentials provider chain

The updated DOMpurify & jQuery libraries contain some security fixes. While we are not aware that these could be used with PrivateBin, for example to bypass DOMpurify filtering of the user provided paste contents to inject malicious code displayed to visitors, upgrading these prevents these from becoming an issue.

Finally, the administration script introduced in the last release, made use of a form of string interpolation that got deprecated in PHP 8.2, causing it to emit warning messages, when running it on that PHP version. It was the only area that needed any changes for PHP 8.2 and our container images have already been using PHP 8.2 for a few months without any issues.

Benefits of switching to the new release

We recommend to upgrade all instances, due to the security fixes in the included DOMpurify & jQuery libraries.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

Changes since version 1.5.1

ADDED: Allow AWS SDK to use default credential provider chain for S3Storage (#1070)
CHANGED: Upgrading libraries to: DOMpurify 3.0.4 & jQuery 3.7.0
FIXED: Addressed PHP 8.2 deprecation warnings (#1092)
FIXED: Expose types JSON-LD incl. configured expiration dates (#1045)

Help wanted & greatly appreciated

What can we offer you in return for your help?

We can offer you our mentorship, if this is your first time participating as a maintainer of an open source software project. We can guide you through submitting your first pull requests and work with you to ensure your change fulfils the communities quality standards, gets merged and makes it into a release.
Your work gets publicly credited. This can help you build up a resume, showing off your growing skill set, in programming as well as your soft skills.
PrivateBin is a smaller project. If you'd like to learn how to participate and contribute in an open source git project, this should be less overwhelming then larger projects.
We do have a decent unit test code coverage, so it is an environment forgiving of mistakes. You may still introduce logical flaws or issues in new features, not yet covered in the tests, but you can rely on the tests preventing any regressions in other areas.
You don't have to be proficient in multiple programming languages, there are a lot of things to improve within either the JavaScript or PHP areas that don't need you to understand the other side, beyond their shared API.
It can be an opportunity to learn about continuous integration tools to automate tasks like tests, security scans, etc.

Plans for future releases

The next minor release will focus on user interface improvements.

Release v1.5.1 - Filesystem purge lookup change & administration script

2022-12-24T06:30:00+01:00

This release reverts a filesystem purge lookup change and adds a script for administrative tasks.

This patch release partially reverts a change to the filesystem backend's purge lookup, adds a script for administrative tasks, catches JSON errors when malformed pastes get uploaded and includes updated libraries for GCS and S3 backends.

Release 1.5.0 contained a simplification to the filesystem backend's purge logic, which could lead to very resource intensive purge cycles on instances with a large storage footprint. This release retains the glob pattern, but re-adds the limited and randomized lookup. The limit gives up searching after 10 times the purge batch size and the randomization prevents re-opening the same, non-expired pastes over and over. Without these mechanisms, eventually all expired pastes got purged, and every further purge reads all pastes from disk, without finding anything, which wastes time and resources.

PrivateBin now adds another script to help perform administrative tasks. The new script, called administration, helps with deleting pastes, removing empty directories, when using the filesystem backend, purging all expired pastes at once and gathering statistics on an instance.

Deleting pastes is relatively easy to do manually with the filesystem and database backends, but more difficult on GCS or S3 storage. The new tool works the same, regardless of backend, letting server administrators delete pastes by ID.

When using the filesystem backend, the purge does not remove empty directories, as they can be reused by new pastes with IDs starting on the same first 2 bytes. These empty directories can now be removed, if desired.

The administration script also can issue a full purge cycle. Instances could disable the automatic purge on paste/comment creation in their configuration and instead use a cron job to run full purges on a schedule. Or it could be issued before a backup, to avoid archiving expired data.

Finally, the script can be used to gather and display statistical information. This includes the total number of pastes the instance hosts, as well as how many of these are expired, of the burn-after-reading type, include discussions and what formatting they use (plain text, source code or markdown).

The release includes smaller improvements to catch a JSON parsing exception when malformed pastes get uploaded to the API and updates the suggested library versions for GCS and S3 storage backends. We had gotten reports of the S3 library in 1.5.0 having emitted deprecation warnings on PHP 8.1.

Benefits of switching to the new release

We recommend to upgrade 1.5.0 instances using the (default) filesystem storage backend as well as instances using S3 storage and PHP > 8.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root.

Changes since version 1.5.0

ADDED: script for administrative tasks: deleting pastes (#274), removing empty directories (#277), purging expired pastes (#276) & statistics (#319)
FIXED: Revert Filesystem purge to limited and randomized lookup (#1030)
FIXED: Catch JSON decode errors when invalid data gets sent to the API (#1030)
FIXED: Support sorting v1 format in mixed version comments in Filesystem backend (#1030)

Help wanted & greatly appreciated

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools that should get you started. For any questions, you can also chat with the maintainers in the discussion area.

Plans for future releases

The next regular release will focus on user interface improvements.

Release v1.5.0 - S3 Storage backend, storage migration script & adding new translations

2022-12-11T06:30:00+01:00

This release adds an S3 storage backend, a storage migration script, and new translations.

This minor release adds support for Simple Storage Service (S3), a storage migration script, adds four new languages to the translations and includes updated libraries.

The new S3 storage backend can be used with Ceph, Amazon Web Services or other S3 providers. A migration script was also provided, which can migrate existing instances from one storage backend to another, including in between the same storage backend types, but with different configurations (i.e. from one directory to another or one database to another).

The release includes several smaller improvements to the MariaDB and MySQL support. It reverts to CREATE INDEX without IF NOT EXISTS clauses (introduced in 1.4.0) which are not supported in MySQL. It also avoids requiring the SUPER privilege for the sql_mode added in 1.4.0. Indexes now also make use of the table prefix, to support multiple instances sharing a single database.

Jdenticons were added as a fourth option for comment icons, in addition to identicons and vizhash (and using none). The new icon type adds a different style and they don't require the PHP GD module to be generated. They are larger in size than identicons, a bit smaller than vizhash and slower to generate than either.

If using the YOURLS URL shortener with a signature and would like to keep it hidden, as of this release a server side integration via a proxy can be used, storing the signature only in configuration.

Benefits of switching to the new release

We recommend to upgrade 1.4.x instances using MariaDB backend and any instance that would like to make use of any of the new features or translations.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root.

Changes since version 1.4.0

ADDED: script for data storage backend migrations (#1012)
ADDED: Translations for Turkish, Slovak, Greek and Thai
ADDED: S3 Storage backend (#994)
ADDED: Jdenticons as an option for comment icons (#793)
CHANGED: Avoid SUPER privilege for setting the sql_mode for MariaDB/MySQL (#919)
CHANGED: Upgrading libraries to: DOMpurify 2.4.6, jQuery 3.6.1, Showdown 2.1.0 & zlib 1.2.13
FIXED: Revert to CREATE INDEX without IF NOT EXISTS clauses, to support MySQL (#943)
FIXED: Apply table prefix to indexes as well, to support multiple instances sharing a single database (#943)
FIXED: YOURLS integration via new proxy, storing signature in configuration (#725)

Help wanted & greatly appreciated

Plans for future releases

The next regular release will focus on user interface improvements.

Release v1.4.0 - Hardening the attachment preview, Google Cloud Storage and Oracle database support & adding new translations

2022-04-09T18:00:00+02:00

This release improves the safety of the SVG attachment preview, adds Google Cloud Storage and Oracle database support, and new translations.

This minor release addresses a security issue with the SVG attachment preview, adds support for Google Cloud Storage (GCS) and Oracle databases, adds four new languages to the translations and includes updated libraries.

The storage system got reworked as part of the new Google Cloud Storage class and when not using the default file storage, the server salt and purge and traffic limiter items are now stored as part of the selected storage backend. It is now possible to run PrivateBin with database or GCS backend without requiring any write access to the data directory - automatic migrations run the first time any of these get accessed and found to be still present in the filesystem.

Benefits of switching to the new release

We recommend to upgrade 1.3.x instances to improve the resolved security issues. At the very minimum, please update your CSP headers in the configuration file to our currently recommended settings. You can check the headers of your instance via our new instance check service.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root.

Changes since version 1.3.5

ADDED: Translations for Corsican, Estonian, Finnish and Lojban
ADDED: new HTTP headers improving security (#765)
ADDED: Download button for paste text (#774)
ADDED: Opt-out of federated learning of cohorts (FLoC) (#776)
ADDED: Configuration option to exempt IPs from the rate-limiter (#787)
ADDED: Google Cloud Storage backend support (#795)
ADDED: Oracle database support (#868)
ADDED: Configuration option to limit paste creation and commenting to certain IPs (#883)
ADDED: Set CSP also as meta tag, to deal with misconfigured webservers mangling the HTTP header
ADDED: Sanitize SVG preview, preventing script execution in instance context
CHANGED: Language selection cookie only transmitted over HTTPS (#472)
CHANGED: Upgrading libraries to: base-x 4.0.0, bootstrap 3.4.1 (JS), DOMpurify 2.3.6, ip-lib 1.18.0, jQuery 3.6.0, random_compat 2.0.21, Showdown 2.0.3 & zlib 1.2.12
CHANGED: Removed automatic .ini configuration file migration (#808)
CHANGED: Removed configurable dir for traffic & purge limiters (#419)
CHANGED: Server salt, traffic and purge limiter now stored in the storage backend (#419)
CHANGED: Drop support for attachment download in IE
FIXED: Error when attachments are disabled, but paste with attachment gets displayed

Help wanted & greatly appreciated

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools that should get you started.

Plans for future releases

The next regular release will focus on user interface improvements.

Vulnerability Report: Persistent Cross-site Scripting (XSS) vulnerability in SVG attachments in PrivateBin < v1.4.0

2022-04-09T18:00:00+02:00

In PrivateBin < v1.4.0 a cross-site scripting (XSS) vulnerability was found. The vulnerability is present since attachments with image preview got introduced in v0.21 of the project, which was at the time still called ZeroBin. The issue is caused by the fact that SVGs can contain JavaScript. This can allow an attacker to execute code, if the user opens a paste with a specifically crafted SVG attachment, and interacts with the preview image and the instance isn't protected by an appropriate content security policy.

As a consequence, we have mitigated the vulnerability in the preview and urge server administrators to either upgrade to a version with the fix or to ensure the content security policy of their instance is set correctly, ideally both. Additionally, we expanded our directory listing tool with a checking mechanism and highly suggest server administrators to check their instance there and, should there be a warning regarding the content security policy adjust the CSP to our suggested one, as it is shown in the configuration preset.

Proof of concept

The vulnerability can be triggered as following:

Create the following SVG as a file:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
 <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
 <script type="text/javascript">
   alert(document.domain);
 </script>
</svg>

Upload it as an attachment to a PrivateBin instance that has attachments enabled and hasn't set the recommended content security policy (in particular, one that has either no content security policy set or that allows * or blob: as a script-src).
Open the paste. (In a real attack scenario this would be done by the victim.)
The SVG is rendered safely as a preview, and script isn't yet executed.
Now (depending on your device) right-click or long tap on the image and open it in a new tab.
Now a blob: URI opens in a new tab with the image and the modal is shown, therefore the script got executed.

Impact

We tried to reproduce the vulnerability and in our assessment, we found out the following:

Any users who use our recommended Content Security Policy (CSP), even older, less strict ones, are not affected by this vulnerability, if a CSP compatible browser is used. All the browsers we tested with did pass on the CSP to the new tab that is opened when viewing the SVG by itself.
As PrivateBin ships with a built-in CSP, we consider this a strong defence in depth against these and related issues. That said, we think the CSP should only be the last layer of defence and as such, we decided to still apply further mitigations for this security issue.
Instances that do not have attachments enabled, are not affected. Even when attachments are uploaded using a third-party client, they can't be rendered when the administrator disables them (the HTML element that they would render in isn't present and before 1.4 this caused an error, we now catch the error and only display the paste text) and thus potential exploits in the attachment file do not apply.
The inline preview (step 4 above) does not execute the script, because browsers explicitly restrict SVGs if the they are is embedded in an img tag to prevent such security issues in images. Thus, SVGs in img tags itself can be considered safe. However, when the user opens the SVG in a new tab, this browser security feature is circumvented. That's why the exploit steps above explain to open the SVG in a new tab. That being said, the impact of the vulnerability is reduced by two factors:
1. The attack explicitly requires user-interaction, i.e. the user has to be tricked into opening the preview in a new tab for some reason. This could realistically be achieved with some social engineering: The markdown formatted text part of the paste could include such an instruction as a big, bold title, or the SVG could be very large and have very small text, which the user might want to zoom into, in order to read.
2. Potential exploit code can only run in a new tab. It still has the same origin (as can be seen in the PoC above, because the domain/origin the script is running on, is shown). However, though, sensitive information like the paste content, potential comments or encryption key (in the URL) is not accessible to the attacker as the context is now a blob-URL – and would anyway consist mostly of things the attacker initially created itself.
  That said, the same origin policy applies and thus, what an attacker could do is read e.g. cookies and local storage data saved in the same origin. As PrivateBin itself does not use any of that, the impact of this vulnerability is limited. However, as PrivateBin is a software for self-hosting, it cannot be excluded that other services run in the same origin (e.g. on the same domain). That's why server administrators may need to evaluate the impact of running arbitrary JavaScript code on their domain/origin where PrivateBin is hosted by themselves.

To summarize, this shows a fairly limited impact, given even if the CSP had not caught the issue, the user still needs to interact with the page and the exploit code cannot access or exfiltrate any data of the PrivateBin instance.

Note: However, take our assessment only as a basis for your own assessment. As explained, depending on your environment, the actual risk may vary if you are hosting other services on the same domain as PrivateBin.

As for the metrics, the impact assessment we have done with CVSS v3.1 results in this: AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N/E:F/RL:U/RC:C/CR:X/IR:X/AR:X/MAV:N/MAC:L/MPR:N/MUI:R/MS:U/MC:X/MI:X/MA:X

Real-life impact

We found two affected instances in our instance lists (wiki, directory) that did not serve a correct Content Security Policy header, had attachments enabled and thus are vulnerable to this attack. We didn't manage to get into contact with the administrators of these sites, though.

In addition to that, we found that multiple instances do seem to either strip our CSP or have it changed to an unsafe setting and have thus expanded our directory service to verify whether our recommend CSP is used or not. (see below)

We have no reports that indicate this vulnerability was or is being actively exploited at the time of this report.

Patches

To fix the problem, we took the following measures (in no particular order):

We apply DOMpurify (a library we already use to sanitize user-submitted HTML via the Markdown format) to the SVG preview, too. It strips script tags and other uncommon security-relevant and potentially malicious tags/properties from the SVG file. So whether you open the SVG in a new tab or not and whether CSP is present and enabled or not does not matter any more, as the displayed SVG is sanitized.
As a further defence in depth mechanism we now send the CSP both as an HTTP header, as well as a meta tag. This protects instance with mis-configured web servers, CDNs, proxy or similar, from stripping or breaking the CSP headers, as they still get the CSP inside of the HTML content itself. Please note though, that the meta tag approach is not as strong as the HTTP header approach and should thus only be considered as a fallback.
The PrivateBin Directory now also scans whether the recommend Content-Security-Policy header is used on a given instance. If you do not want to have your website appear in the list, but check it manually you can use a separate check page there.

The code-changes in PrivateBin can be found in https://github.com/PrivateBin/PrivateBin/pull/906.

Note: Please note that we explicitly chose to not apply DOMPurify if you download the (SVG) attachment with the download button. Subsequently, if a user would manually opens the downloaded SVG in the browser, it will be opened from the file:// protocol and thus from a different origin, so all reference to the download location is lost and no more security risk is associated with that, than opening any website or local HTML file. Thus, the SVG file with stay intact in it's original form, if you download the attachment.

We consider the execution of code from attachments outside of the PrivateBin instance's context to be out of scope to mitigate (i.e. malware in executables, office documents macros, PDF scripts), as all of these require client side mitigations to be applied to all such downloaded file types, independent on where they get downloaded from.

Workarounds

We strongly recommend you to upgrade to our latest release, especially as we also upgraded outdated and potential vulnerable libraries (see below). However, here are two workarounds that may help you to mitigate this vulnerability:

Update the CSP in your configuration file to the latest recommended settings and check that it isn't getting reverted or overwritten by your web server, reverse proxy or CDN, i.e. using our offered check service.
Deploying PrivateBin on a separate domain may limit the scope of the vulnerability to PrivateBin itself and thus, as described in the “Impact” section, effectively prevent any damage by the vulnerability to other resources you are hosting.
As explained in the impact assessment, disabling attachments also prevents this issue.

References

We highly encourage server administrators and others involved with the PrivateBin project to read-up on how Content-Security-Policies work, especially should you consider to manually adjust it:

https://content-security-policy.com/
https://developer.mozilla.org/docs/Web/HTTP/CSP
https://developers.google.com/web/fundamentals/security/csp/

Also please note that if multiple headers are set (as e.g. done via our now introduced meta tag) browsers should apply the most restrictive set of the policies, as per the CSP specification.

For more information

Please notice we also upgraded jQuery that was reported to us as being vulnerable both by our automated container security scanning as well as by users. By doing so, we also updated all other dependencies we use. Our tooling identified the following vulnerabilities in jQuery:

CVE-2020-11023
CVE-2020-11022

In a limited assessment about these when we were made aware of them we could not find any immediate risk, but nevertheless, we encourage users to upgrade to be on the safe side.

Finally, we also upgraded zlib to address CVE-2018-25032.

Timeline

2022-02-22 – Initial contact by reporter.
2022-02-25 – Reporter sends in a detailed report.
2022-02-26 – Report gets reviewed, initial findings around the content security get shared and reporter withdraws report.
2022-04-09 – Vulnerability details published.

Credits

This vulnerability was reported by Ian Budd, Nethemba s.r.o, which we'd like to thank for that.

In general, we'd like to thank everyone reporting issues and potential vulnerabilities to us.

Release v1.3.5 - Fixing several smaller issues, adding new translations

2021-04-05T20:00:00+02:00

This release fixes a number of smaller issues and adds new translations.

This bug fix releases addresses a number of smaller issues and regressions, adds four new translations and includes updated libraries. Links in pastes now by default open in a new browser tab or window. The project information text and link is now a configuration option.

Benefits of switching to the new release

We recommend to upgrade 1.3.x instances to address these issues.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root.

If you have enabled the fileupload setting and use a custom cspheader, please consider adding allow-downloads to the sandbox property. This lets users of the Google Chrome browser, version 83 or higher, download attachments - inline display of images, media or PDFs files was not affected by this change in Chrome's sandbox behaviour.

Changes since version 1.3.4

ADDED: Translation for Hebrew, Lithuanian, Indonesian and Catalan
ADDED: Make the project info configurable (#681)
CHANGED: Upgrading libraries to: DOMpurify 2.2.7, kjua 0.9.0 & random_compat 2.0.18
CHANGED: Open all links in new window (#630)
FIXED: PDF display in Firefox (#630)
FIXED: Allow pasting into password input dialog (#630)
FIXED: Display of expiration date in email (#630)
FIXED: Allow display of durations in weeks (#630)
FIXED: Avoid exposing burn-after-reading messages from cache (#630)
FIXED: Only display the dropzone when it should (#630)
FIXED: Detect delete token properly (#630)
FIXED: Sanitize output from Helper.urls2links() (#630)
FIXED: Avoid recreation of existing pasteurl element when calling URL shortener (#630)
FIXED: Downloads in Chrome >= 83 (#634)
FIXED: Display of empty files (#663)
FIXED: Improve OpenGraph attributes (#651)
FIXED: Reset to configured burn-after-reading, discussion and expiration settings (#682)
FIXED: Italic segment of project information (#756)

Help wanted & greatly appreciated

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools that should get you started.

Plans for future releases

The next regular release will focus on user interface improvements.

Release v1.3.4 - Fixing HTML entities, custom expiration, pasting into password field

2020-03-22T09:00:00+01:00

This release fixes HTML entities, custom expiration and pasting into password field.

This bug fix releases resolves further HTML entity encoding issues, the use of custom expiration options in the email function, pasting into the password dialog on pastes with attachments and also updates the identicon library to 2.0.0, which increases the minimum required PHP version to 5.6.

Benefits of switching to the new release

We recommend to upgrade 1.3.x instances to address these issues.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root.

Changes since version 1.3.3

CHANGED: Minimum required PHP version is 5.6, due to a change in the identicon library and to use php's native hash_equals()
CHANGED: Upgrading libraries to: identicon 2.0.0
FIXED: Support custom expiration options in email function (#586)
FIXED: Regression with encoding of HTML entities (#588)
FIXED: Unable to paste password on paste with attachment (#565 & #595)

Help wanted & greatly appreciated

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools that should get you started.

Plans for future releases

The next regular release will focus on user interface improvements.

Release v1.3.3 & v1.2.3 - Fixing HTML entity double encoding issues introduced in 1.3.2 & 1.2.2

2020-02-16T12:00:00+01:00

This release fixes HTML entity double encoding issues introduced in versions 1.3.2 and 1.2.2 of PrivateBin.

In the efforts to prevent the unencoded strings to cause XSS issues down the line in releases 1.3.2 and 1.2.2, we had some strings getting their HTML entities encoded twice. This caused some display glitches as well as preventing the URLs in paste texts to get converted to links.

This bug fix releases resolves these encoding issues, expands the XSS protection to the server side templating, updates some missing translation strings for the mailing feature (in 1.3.3 only) and also updates the DOMpurify library to 2.0.8.

Benefits of switching to the new release

We recommend to upgrade 1.3, 1.3.1, 1.3.2, 1.2, 1.2.1 and 1.2.2 instances to address these issues.

We do offer a backport of these fixes for the 1.2.x versions of PrivateBin. You may choose to use version 1.2.3 over 1.3.3, if you do need to support legacy browsers with incomplete or missing Webcrypto API, like IE, non-Chromium based Edge or some ESR releases.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root.

Changes

in 1.3.3 since version 1.3.2

CHANGED: Upgrading libraries to: DOMpurify 2.0.8
CHANGED: Several translations got updated with missing messages
CHANGED: Introduce HTML entity encoding on server side (#581)
FIXED: HTML entity double encoding issues introduced in 1.3.2 (#560)

in 1.2.3 since version 1.2.2

CHANGED: Upgrading libraries to: DOMpurify 2.0.8
CHANGED: Introduce HTML entity encoding on server side (#581)
FIXED: HTML entity double encoding issues introduced in 1.3.2 (#560)

Help wanted & greatly appreciated

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools that should get you started.

Plans for future releases

The next regular release will focus on user interface improvements.

Release v1.3.2 & v1.2.2 - Fix for persistent XSS vulnerability in filenames of attached files

2020-01-11T15:00:00+01:00

This release fixes a persistent XSS vulnerability in filenames of attached files in PrivateBin.

On 25th of December 2019, an issue was discovered and fixed, which allowed the user provided attachment file name to inject HTML under certain conditions, leading to a persistent Cross-site scripting (XSS) vulnerability. This release includes an improved solution, which addresses the issue on a broader scope, avoiding this to reoccur in other areas of the code in the future.

Further details on this is an issue and its implications can be found in our report on the vulnerability. It also describes methods to check if your browser is currently affected by the issue. If it is, please consider updating your browser.

Benefits of switching to the new release

We recommend to upgrade 1.3, 1.3.1, 1.2 and 1.2.1 instances to address this issue, even if the instance doesn't have fileuploads enabled and uses the recommended CSP header to mitigate XSS attacks.

Due to the seriousness of the issue, we do offer a backport of the fix for the 1.2.1 version of PrivateBin, that also includes updated JavaScript libraries. You may choose to use that version over 1.3.2, if you do need to support legacy browsers with incomplete or missing Webcrypto API, like IE, non-Chromium based Edge or some ESR releases.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root.

Changes

in 1.3.2 since version 1.3.1

ADDED: Translation for Ukrainian (#533)
ADDED: Option to send a mail with the link, when creating a paste (#398)
ADDED: Add support for CONFIG_PATH environment variable (#552)
CHANGED: Upgrading libraries to: base-x 3.0.7, DOMpurify 2.0.7 & Showdown 1.9.1
FIXED: HTML injection via unescaped attachment filename (#554)
FIXED: Password disabling option (#527)

in 1.2.2 since version 1.2.1

CHANGED: Upgrading libraries to: bootstrap 3.4.1, DOMpurify 2.0.7, jQuery 3.4.1, kjua 0.6.0, Showdown 1.9.1 & SJCL 1.0.8
FIXED: HTML injection via unescaped attachment filename (#554)

Help wanted & greatly appreciated

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools that should get you started.

Plans for future releases

The next regular release will focus on user interface improvements.

Vulnerability Report: Persistent XSS vulnerability in filename of attached file in PrivateBin

2020-01-11T15:00:00+01:00

On 24th of December 2019 one of the property based unit tests reported a failure. Upon investigation, @elrido discovered that the failure was due to unescaped HTML, which allowed the user provided attachment file name to inject HTML under certain conditions leading to a persistent Cross-site scripting (XSS) vulnerability. After committing an initial fix to the master branch, the issue was reported on 25th of December. Vulnerability write-up done by @rugk and @elrido.
The vulnerability has been fixed in PrivateBin v1.3.2 & v1.2.2. Admins are urged to upgrade to these versions to protect the affected users.

Affected versions

Any PrivateBin version since 1.2.

Conditions

The configuration setting fileupload has to be enabled, as 1.3 displays an error when trying to open a paste with attachment.
The CSP header rules don't get applied. For example:
- They are unsupported or disabled in the visitors browser.
- They are filtered out by a some proxy server at the server or client side.
- The header is disabled/commented in the PHP-logic.
- The rules have been relaxed in the cspheader configuration setting.
A paste with a malicious filename is created.
A visitor of that paste clicks on the "Clone" button.

Proof of concept

The following method is just one possibility to exploit this issue and is provided as a proof of concept with steps to reproduce the issue. To avoid having to create an actual file with a rogue filename, one could use the Python CLI client for PrivateBin and edit line 56 in format.py as follows:

-        self._attachment_name = path_leaf(path)
+        self._attachment_name = '<script>alert("☹️");//<a'

The paste then can be created on a vulnerable instance:

$ python pbincli/cli.py send -t " " -f /dev/null -s https://privatebin.net/

Visiting the created paste on a vulnerable instance, with fileupload enabled and the CSP header weakened or disabled, and clicking the clone button will insert the HTML unescaped. In the above example, a pop-up would appear, when the script is executed.

Impact

On a vulnerable site pastes with malicious filenames can be created and users visiting these could inadvertently trigger the code execution when they click the "Clone" button. They could be instigated to do so via social engineering, like a paste text suggesting to "clone and share" the paste in question.

The attached file itself doesn't have to be empty and could be an image or document that would still be displayed inline as usual. The execution of the script triggered by clicking on the "Clone" button may occur silently in the background without showing any noticeable signs in browser. It may for instance be used to track visitors, start drive-by-downloads or similar. While we focus on script injection here, as it is the easiest exploit vector, it has to be said that anything else can be injected like CSS, images, videos, although the default CSP will block inline CSS and images, e.g.

On first visit, the filename isn't visible and is properly escaped when inserted into the download attribute. Only when clicking the "Download attachment" link would open a file save dialog with an odd name pre-filled, although browsers will convert illegal characters into valid ones, so it may not be identical to the one provided. Only when the "Clone" button has been clicked and after the exploit has already been triggered, the filename gets displayed. Note that an attacker can of course prevent this indicator of compromise to be shown and e.g. change the displayed text or obfuscate the filename by starting it with something harmless, like image.png, before opening the HTML tag.

Impact restrictions

The impact is mitigated by the fact that the vulnerability is, as far as our investigation concluded, paste-specific, i.e. opening a vulnerable paste can only compromise this one paste and no other pastes.

Furthermore, as stated before, the impact is mitigated by the fact that we deploy a strong CSP that, by default, does not allow inline JS or other potentially easy methods that would allow an easy exploitation of the vulnerability.
That said, we have to make users aware, that there may always be tricks to bypass such a CSP and the simple injection of HTML tags, e.g. destroying, faking or somehow phishing an HTML page does always remain a possibility.

As such, we treat this as a security vulnerability with medium severity. It is critical on it's own, but we believe that the deployed security mechanisms should prevent an exploit in practice in most cases.

Real-life impact

We checked all instances listed in the PrivateBin directory in the Wiki and didn't find any 1.1, 1.2 or 1.3 instances that had the CSP headers disabled or in a state we know to be vulnerable. We used the following script, that may be adapted to check the CSP headers of any single instance:

for URL in $(
    curl -s https://raw.githubusercontent.com/wiki/PrivateBin/PrivateBin/PrivateBin-Directory.md | grep -Po '^http.*?(?= )'
)
do
    echo -n "$URL: "
    curl -sLI $URL | grep -Poi 'content-security-policy.*script-src.?\K.*?(?=;)' || echo 'No CSP detected!'
done

Some of the above sites do offer file uploads. On these instances, it is still possible that a visitor could have CSP support disabled in their browser, i.e. via a transparent proxy at their internet uplink or due to a browser plugin or some other locally installed, misguided security solution.

Important: This scan is only a cursory check and must not be taken as a security analysis of any means! You are always responsible for the security of your own instance. Please do check it manually!

Mitigation

As server administrators can't detect if a paste contains file attachments at all (apart from their size) in version 1.3 and due to the encrypted filename in older versions, as well as the risk for clients that don't apply the CSP settings, we urge them to upgrade to versions 1.3.2 or 1.2.2.

If you use v1.3, you could disable the fileupload setting to prevent pastes from getting displayed that may contain this vulnerability. Note that this will break all existing pastes with uploads, however, so we do not recommend this, but advise you to upgrade to a fixed version instead.

Further information

We want to make potential third-party client authors aware of this vulnerability and urge them to double-check their implementations. If they develop a client that displays untrusted foreign data from a paste in a HTML site, please make sure to escape it to prevent XSS attacks. Such attacks can only be prevented when the paste is displayed, a mitigation when a paste is created is pointless, as a different client can be used during creation.

We do also acknowledge and want to highlight the benefit of the CSP, which has first been introduced in PrivateBin v1.0.

However, we want to make you again aware that a whitelist-based CSP as we use, may sometimes still be bypassed, e.g. if you host a copy of the Angular library on the same domain as your PrivateBin instance. We are aware of that and do consider upgrading to a stronger CSP in the future.

Issue discovery

While it is satisfying that our hard work on introducing unit tests has payed off in the discovery and mitigation of this vulnerability, it does also show a limitation of unit testing. A third party doing a code review would have certainly focused on how the project handles user provided input and may have discovered this much quicker.

The discovery wasn't due to the unit test checking for HTML input to get properly escaped, on the contrary, the test assumed input would not be changed. So other instances of HTML tags generated would have happily passed the test. Only when the test generated a fragment of a link (<a) it failed, because the DOM silently removed it when it inserted the string, as links within links aren't allowed. While the test was written to throw arbitrary strings at the AttachmentViewer.moveAttachmentTo() method, the test would only check that these got inserted into the DOM unchanged, oblivious of their potential significance when interpreted as HTML.

The test had been introduced on December 3rd, 2017, 570 commits ago. Every commit on master and in PRs since introduction in that commit triggers these tests to run for every supported PHP version. Additional test cycles get run on developers local environments during working on commits. Hence the test suite must have run a few thousand times, testing 100 random strings each time. And only after more then 2 years a string containing <a got generated, triggered the error condition and 22 shrinks later the smallest failing test case was presented as:

Failed after 65 tests and 22 shrinks. rngState: 8b8f0d4ec2a67139b5; Counterexample: "image/png"; ""; "\u0000"; "<a"; "";

Discussion about a potential problem with that code, did spark last September, when the vulnerable code part was changed to the one before before the current fix, but was incorrectly judged as not being a problem, because all of our translation strings are hardcoded. The fact that we do actually add some untrusted user-provided content, wasn't considered at that point.

It should also be mentioned, that the coverage report released for version 1.3.1 did highlight the line that caused this vulnerability as not being covered during testing:

So, in conclusion, it is great to have all of these tools at our disposal, but the code quality would benefit a lot more from having more eyeballs and brains on it.

Timeline

2019-12-24 – Property based unit test fails in a commit pushed to a PR.
2019-12-25 – Issue investigated, preliminary patch and issue description published.
2019-12-30 – Further investigations, proof-of-concept exploit demonstrated on a vulnerable test instance.
2020-01-03 – Discussed broader mitigation of user provided content injections, reviewed other possible cases.
2020-01-04 – Published a second patch based on review, escapes HTML in translation.
2020-01-05 – Started writing vulnerability report.
2020-01-07 – Backported fix for 1.2.1.
2020-01-11 – Release published.
2020-01-11 – Vulnerability details published.

Release v1.3.1 - Improve error messages for unsupported browsers

2019-09-22T21:30:00+02:00

This release improves the display of appropriate errors for unsupported browsers/configurations.

Since the release of version 1.3 only two months ago we received reports on a surprising number of corner cases with certain browser versions and protocols in which the new release didn't work, while 1.2.1 still did. The release addresses most of these or at least aims to provide a meaningful error message with hints what the user may do to avoid these (switching to HTTPS, using a different browser or being limited to partial functionality).

We also have been provided with a Bulgarian translation and several improvements to the bootstrap template, cloning pastes and the drap & drop file upload. The URL shortener now also supports JSON APIs and the default size limit was increased to 10 MiB.

Before the 1.3 release we had tested mainly in Firefox and Chrome, but none of the core developers had easy access to Windows based browsers (Edge, IE) or Mac (Safari). We also missed that Chrome disables the webcrypto API used in 1.3 to replace the SJCL cryptographic library, when accessing the site via HTTP. It didn't do this in our local testing environments, as localhost is considered safe by it, even when not accessed via HTTPS. Other quirks discovered were issues when accessing PrivateBin via Tor and i2p networks. The Torbrowser disables webassembly due to security concerns, which prevented these clients to create or read pastes.

To facilitate testing of such quirks and having access to more browsers versions, we applied for a sponsored browserstack account. This helped us improving the browser feature detection. In particular the following cases got covered: - When a modern browser has webassembly disabled (i.e. for security), it displays a warning, but still can create and read uncompressed pastes, just not open compressed ones. - Browsers with a lack for webcrypto API on an HTTP site get suggested to switch to HTTPS (requires support by the server). - Browsers with a lack for webcrypto API, async or ES6 support get an error requesting to switch to a modern browser. - Internet Explorer remains unsupported, but now get an appropriate error requesting to switch to a modern browser.

Benefits of switching to the new release

We recommend to upgrade 1.3 instances to improve the support for Chrome and older browsers get more appropriate error messages.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root.

The default size limit got increased from 2 to 10 MiB. If you didn't configure a custom size, you may have to adjust your PHP and webserver settings to be able to use the new limit to the full extent.

If you use the MySQL database backend and don't allow the PrivateBin use to ALTER TABLES, you have to manually change one columns type and UPDATE the database version (replace "prefix_" with your own table prefix, if used):

ALTER TABLE prefix_paste MODIFY COLUMN data MEDIUMBLOB;
UPDATE prefix_config SET value = "1.3.1" WHERE id = "VERSION";

PostgreSQL and SQLite don't require this change.

Changes since version 1.3

ADDED: Translation for Bulgarian (#455)
CHANGED: Improved mobile UI - obscured send button and hard to click shortener button (#477)
CHANGED: Enhanced URL shortener integration (#479)
CHANGED: Improved file upload drag & drop UI (#317)
CHANGED: Increased default size limit from 2 to 10 MiB, switch data from BLOB to MEDIUMBLOB in MySQL (#458)
CHANGED: Upgrading libraries to: DOMpurify 2.0.1
FIXED: Enabling browsers without WASM to create pastes and read uncompressed ones (#454)
FIXED: Cloning related issues (#489, #491, #493, #494)
FIXED: Enable file operation only when editing (#497)
FIXED: Clicking 'New' on a previously submitted paste does not blank address bar (#354)
FIXED: Clear address bar when create new paste from existing paste (#479)
FIXED: Discussion section not hiding when new/clone paste is clicked on (#484)
FIXED: Showdown.js error when posting svg qrcode (#485)
FIXED: Failed to handle the case where user cancelled attachment selection properly (#487)
FIXED: Displaying the appropriate errors in older browsers (#508)

Help wanted & greatly appreciated

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools that should get you started.

Plans for future releases

The next release will focus on user interface improvements.

Release v1.3 - Fixing mangled URLs, switching encryption & compression libraries

2019-07-09T18:28:00+02:00

This release switches the used encryption and compression libraries and addresses several problems with mangled URLs and pastes.

We fixed several issues in this release. We now tell Chrome not to send the whole page, including the decrypted text, to it's translation services. Thanks to the use of blob instead of data URI's, Chrome can now deal with attachments larger then 2 MiB. The raw text mode escapes HTML correctly again (a regression introduced in 1.2). PrivateBin can now handle URLs mangled by Facebook.

Translations for Czech has been added since the last release.

We threat modeled the application in preparation for the changes in the API, JSON format and encryption.

The main change of this release was the switch from the SJCL and rawdeflate JavaScript libraries to the browser integrated WebCrypto API and zlib C library (via WebAssembly) as well as various modernizations of our use of JavaScript. We still fully support reading older pastes and comments, but newly generated pastes use a different, more efficient and flexible format. Some of these changes lead to us dropping the support for Internet Explorer and we suggest to use Edge instead, if no other modern browser is available (see Appendix A below).

The change to WebCrypto API means that the cryptographic functions are now handled by the browser integrated libraries instead of code that has to be transferred from the webserver to the client. While this can't prevent a malicious party to inject logic to extract the key or decrypted contents, it does increase the trust users can have in the cryptographic functionality of PrivateBin as well as speed up both initial page load as well as the en/decryption itself.

Over the years we encountered several cases where the deflate implementation used in the rawdeflate JavaScript library produced results that couldn't be decompressed by itself or other deflate implementation. While the latter mainly affected third-party CLI clients, the first lead to pastes that couldn't be read even by PrivateBin itself. We had initially planned to use the pako JavaScript library, but during implementation of the new format found that the zlib C library used in most other languages for deflate support can be used in JavaScript as well, via compilation into WebAssembly. This is a very stable library with no currently known bugs and even performs better then pako.

Server operators now have an additional configuration option that lets them disable compression. While the compression before encryption reduces the size of most text, source code, markdown pastes and text comments drastically, when having file upload enabled and mostly using an instance to share already compressed files (office documents, PNG or JPG images, etc.) this slows down the creation of the pastes unnecessarily and without gain. Furthermore some security minded administrators may wish to disable compression to avoid potential security risks that would make brute forcing keys easier for shorter, compressed pastes.

As usual we have also upgraded all used libraries to their latest releases. The identicon library now requires PHP 5.5, so this is the new minimum required PHP version.

Finally the newly used JSON format and API was taken as an opportunity to implement some, otherwise breaking, changes like the use of base58 for the hash key encoding instead of base64, which addresses the Outlook mail client stripping trailing equal signs from URLs. The number of iterations in the PBKDF2 key derivation got increased from 10k to 100k to make it more costly to brute force the password of a paste. The server now uses Fowler–Noll–Vo checksums instead of md5 to generate unique paste IDs.

Benefits of switching to the new release

Due to some rather annoying bugs in the raw paste view and with URLs mangled by Facebook and Outlook, we do recommend an upgrade on instances that are more widely used. While most users never encountered cases where the pastes got mangled in the deflate compression, users that frequently upload office documents and certain source code and compiler outputs would trigger this rather reliably. There are also several improvements that increase the security of the encryption.

Update procedure

Two new configuration options, compression and httpwarning got introduced.

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root. Note that the latest docker containers use different user IDs then the older ones, so you will have to change the ownership of the attached data volume.

If you do have to use the new release on a PHP 5.4 environment, you can attempt to change the icon option to vizhash or none and decrease the MIN_PHP_VERSION in the lib/Controller.php file.

Changes since version 1.2.1

ADDED: Translation for Czech (#424)
ADDED: Threat modeled the application (#177)
ADDED: Made compression configurable (#38)
CHANGED: Minimum required PHP version is 5.5, due to a change in the identicon library
CHANGED: Minimum required browser versions are Firefox 54, Chrome 57, Opera 44, Safari 11, Edge 16, due to use of WebCrypto API, async/await, ES6 & WebAssembly features - all Internet Explorer versions are incompatible
CHANGED: JSON and encryption formats were changed to replace SJCL library by browser integrated WebCrypto API (#28, #74)
CHANGED: Replaced rawdeflate.js with zlib.wasm to resolve decompression failures and gain compatibility with standard deflate implementations (#193, #260, #328, #434, #440)
CHANGED: Increase PBKDF2 iterations to 100k (#350)
CHANGED: Replaced last use of MD5 with Fowler–Noll–Vo checksum which produces the exact length we need for the paste ID (#49)
CHANGED: Simplified some PHP code & renamed PrivateBin class into Controller, to make MVC pattern use more obvious (#342)
CHANGED: Upgrading libraries to: identicon 1.2.0, random_compat 2.0.18, jQuery 3.4.1, Showdown 1.9.0, DOMpurify 1.0.11 & kjua 0.6.0
FIXED: Prevent Chrome from sending content of paste to Google for translation (#378)
FIXED: To support attachments larger then 2 MiB in newer Chrome versions, we switched to blob instead of data URIs (#432)
FIXED: Since Outlook strips trailing equal signs in links, the key in URL hash is now base58 encoded, instead of base64 (#377)
FIXED: Facebooks started injecting parameters into shared URLs for tracking that lead to inaccessible pastes (#396)
FIXED: Properly escaped HTML in raw text mode (#358)
FIXED: Made download links better readable in the dark bootstrap theme (#364)
FIXED: Allow Letsencrypt bot to access on apache servers (#413)

Help wanted & greatly appreciated

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools that should get you started.

Plans for future releases

The next release will focus on user interface improvements.

Appendix A - Browser feature compatibility

The following table provides an overview of when support of the newly used JavaScript features got introduced in the major browsers:

Browser/Feature	async/await	Web Crypto API	WebAssembly	ECMAScript 2015 (ES6)	first version to support all features	Release date
Chrome	55	37	57	51	57	2017-03-09
Edge	15	12	16	15	16	2017-09-26
Firefox	52	34	52	54	54	2017-06-13
IE	no	11	no	11	none	none
Opera	42	24	44	38	44	2017-03-21
Safari	10.1	11	11	10	11	2017-09-19

Except for Internet Explorer, all major browsers support the new features since March to September 2017. Internet Explorer 11 lacks support for WebAssembly (used for zlib compression) and async/await. The WebCrypto API is based on Promise interfaces and we use await to avoid having to rewrite large code segments from synchronous function calls to Promise-based, asynchronous logic. In light of this, we decided to drop support for Internet Explorer, as Windows users that can't install other browsers can use PrivateBin with the Edge browser instead.

Release v1.2.1 - Fix for low entropy key vulnerability in legacy browsers

2018-08-11T22:30:00+02:00

This release fixes a low entropy key vulnerability in PrivateBin affecting legacy browsers

On 31st of July 2018, @cryptolok reported a cryptographic vulnerability in PrivateBin due to the incorrect use of SJCL when used on very old browsers. When creating a paste using any ZeroBin version or PrivateBin up to and including 1.1.1 on a browser without web crypto API support (Firefox<21, Chrome<15, Safari<5, IE<11) the key may have been generated without sufficient entropy. PrivateBin 1.2 was not affected, because the support for those browser versions got removed in the JS refactoring.

This release re-adds support for those legacy browsers and ensures they generate the key with sufficient entropy. In the next release of PrivateBin we will permanently drop legacy browser support and switch to the web crypto API exclusively. This release ensures that there is at least one release available that supports both legacy browsers and has the entropy issue fixed.

Benefits of switching to the new release

If you are still using PrivateBin version 1.1.1 or ZeroBin, upgrading to this release will ensure that you retain legacy browser support and fix the low entropy key vulnerability in your current version. If you already upgraded to PrivateBin 1.2 and don't need to support these very old browser versions (released before October 2013) then you could consider skipping this release.

Update procedure

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root.

Note that this is the first release that is signed with the new signing key (fingerprint: 28CA 7C96 4938 EA5C 1481 D42A E11B 7950 E9E1 83DB). This key is intended to be used for signing releases from now on.

Changes since version 1.2

ADDED: Add support for mega.nz links in pastes and comments (#331)
CHANGED: Added some missing Russian translations (#348)
CHANGED: Minor PHP refactoring: Rename PrivateBin class to Controller, improved logic of some persistence classes (#342)
CHANGED: Upgrading DOMpurify library to 1.0.7
FIXED: Ensure legacy browsers without webcrypto support can't create paste keys with insufficient entropy (#346)
FIXED: Re-add support for old browsers (Firefox<21, Chrome<31, Safari<7, IE<11), broken in 1.2, will be removed again in 1.3

Vulnerability Report

2018-08-11T22:30:00+02:00

On 31st of July 2018, @cryptolok reported a cryptographic vulnerability in PrivateBin due to the incorrect use of SJCL when used on very old browsers. Vulnerability write-up done by @rugk and @elrido.
The vulnerability has been fixed in PrivateBin v1.2.1. Admins are urged to upgrade to this version to protect the affected users.

Affected versions

Any ZeroBin and PrivateBin lower then version 1.2 (which did not support the affected browsers) since the first commit to ZeroBin.

Conditions

The condition is only met when a paste is first created, during the generation of a random key used for the encryption of the paste and any subsequent discussion topics. Viewing the paste does not pose a risk in itself, as the key already is known to the viewer.

Browsers that expose the web crypto API function crypto.getRandomValues() and nodeJS (in case of the CLI client) are not affected. See the timeline of browser releases with web crypto support in the appendix below.
For browser versions that do not provide this API, SJCL provides a fallback using collected randomness from mouse movements, keypresses, motion sensors, etc. While ZeroBin and PrivateBin did implement this fallback and a check to ensure that enough entropy got collected, the incorrect use of the randomwords function in SJCL allowed a premature generation of the paste key, even if not enough entropy had been collected. The collection of entropy takes around 20 - 90 seconds, depending on the performance of the system (minimum and maximums as found during testing on 800 Mhz single core and 2.7 GHz quad core CPU systems).

Steps to reproduce

Find a way to install an affected browser or use a system that still has such an old browser installed. Our tests if the mitigation were performed primarily using Firefox 10.
Visit a PrivateBin or ZeroBin site running a release earlier then version 1.2.
Quickly paste some content into the text area, set options and hit send within less then 20 - 60 seconds (depending on the performance of the environment).

If the entropy is not ready, PrivateBin before version 1.2 would suppress any error, generate the key regardless and submit the paste. PrivateBin 1.2 doesn't support these old browsers, sending the paste to the URL "undefined" and fails to submit the paste. PrivateBin v1.2.1 asks you to move your mouse, etc. to create entropy on these older browsers, as intended.

Impact

On affected browsers the pastes may have been generated with low entropy. Viewing pastes on any browser does not pose a risk. When comments are posted on such a paste, the low entropy key gets reused. There is no obvious way to detect a key with insufficient entropy. It will have the same length as usual and seem random to the human eye.

We have to assume that pastes generated with a low entropy key can be brute forced easier then with a completely random key. With a lower entropy, the total amount of different generated keys would be lower then 2^256 (we use 256bit long keys).

Real-life impact

We have not conducted any research on how frequent such affected pastes are. However, on the instance of one of the maintainers, the oldest found paste was created in 2015 and so seems unlikely to be affected, while on PrivateBin.net the oldest paste is from 2017. By default most pastes are set to expire within a week. A user would have had to set the expiration explicitly to "never" for it to be still available.

At the time of the first ZeroBin commit affected by this issue in April 21st 2012, the then current releases of Chrome and Safari already supported the required web crypto API call and were not affected. One and a half years later, end of October of 2013, releases of Firefox, Internet Explorer, iOS and Android where available that supported the new API also and were no longer affected. Opera as of March 2014 is also unaffected.

When ZeroBin was first released, about 60% of the used browsers were affected (see browser market share in the appendix below). By the end of 2013 the market share of browsers still affected in their latest release was below 3%. Even during this time pastes created with affected browsers may have had sufficient entropy as the key is generated just before sending the paste, as long as the user creating the paste spent more then ~30 seconds on the page. On the other hand, users that send a paste "too quickly" could have easily created a paste with a key with limited entropy within a few seconds.

Mitigation

Users that know of old pastes generated with outdated browsers may want to clone the pastes using a more recent browser and delete the old paste, if they still have the delete token URL.

Administrators should update their instances to PrivateBin version 1.2.1.

Timeline

2018-07-31 – Reporter raised an issue, after reviewing the PrivateBin source code.
2018-07-31 – Receipt confirmed, started preparing vulnerability report to collect findings.
2018-08-01 – Issue confirmed, research of versions and timelines, aquired access to environement with legacy browsers for testing.
2018-08-04 – Patch developed and tested to resolve the issue in legacy browsers.
2018-08-05 – Worked on vulnerability report, release preparations.
2018-08-xx – Release published & Vulnerability details published.

Appendix

Release history of unaffected browsers / affected ZeroBin versions

2014-04-14 - Windows Phone 8.1
2014-03-04 - Opera 20
2013-10-31 - Android 4.4
2013-10-17 - Internet Explorer 11
2013-09-18 - iOS 7.0
2013-05-14 - Firefox 21
2012-04-21 - first commit of ZeroBin
2011-10-25 - Chrome 15
2010-06-07 - Safari 5

Disclaimer: In the case of Chrome, Android, iOS and Windows Phone, there may have been earlier versions that were not affected, but we did not have access to any of these (in the case of iOS version 4.3.2 was found to be affected). See the details on the tested browser versions below.

Browser market share in April 2012

Source: Statista - Market share of browsers worldwide since 2009

IE 30.8%
Chrome 28.24%
Firefox 22.5%
Safari 8.72%
Opera 3.62%
Android 2.31%
UC Browser 0.74%

Source code of the used SJCL-Test page

<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <title>SJCL randomwords test</title>
  <meta name="robots" content="noindex, nofollow">
  <meta name="googlebot" content="noindex, nofollow">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <script type="text/javascript" src="https://bitwiseshiftleft.github.io/sjcl/sjcl.js"></script>
  <script type="text/javascript">
        // IE polyfill
        if (!Date.now) {
            Date.now = function now() {
                return new Date().getTime();
            };
        }

        function log(string) {
            var e = document.createElement('p');
            e.innerHTML = string;
            document.body.appendChild(e);
        }

        var time = Date.now(),
            i = 0;

        sjcl.random.addEventListener('progress', function() {
            log('waiting ... ' + i);
            i++;
        });

        sjcl.random.addEventListener('seeded', function() {
            log((Date.now() - time) + ' milliseconds');
        });

        // set the paranoia level explicitly:
        sjcl.random.setDefaultParanoia(10);

        log("without startCollectors");
        setTimeout(function() {
            log("startCollectors")
            // start random number generator collector.
            sjcl.random.startCollectors();
            log(
                'progress so far is ' + (sjcl.random.getProgress() * 100) +
                '%, isReady says: ' + sjcl.random.isReady() +
                ', 8 randomwords are: ' + sjcl.random.randomWords(8)
            );
        }, 1000);

        log(
            'progress so far is ' + (sjcl.random.getProgress() * 100) +
            '%, isReady says: ' + sjcl.random.isReady() +
            ', 8 randomwords are: ' + sjcl.random.randomWords(8)
        );
    }
  </script>
</head>
<body></body>
</html>

Details on the tested browsers versions

The following screenshots were collected while running the above SJCL library test website to detect browsers that fall back on collecting entropy instead of the web crypto API for generating random numbers. In some cases we didn't have enough versions at our disposal to find the precise version and just documented the state of those available to us.

The test website had to be offered via HTTP, since most of the affected older browsers don't support modern TLS 1.3 and certificate authorities and so would fail to connect using HTTPS.

Firefox

Version 21 (left) was the first to support the web crypto API, while the much older version 3 did not (right):

Chrome

The oldest version at our disposal was Chrome version 15 which already did support the web crypto API. No screenshots were collected.

Safari

Version 5 (left) did support the web crypto API, while version 4 did not (right):

Internet Explorer

Version 11 did support the web crypto API, while versions 8 and 10 did not (below):

Opera

Version 20 did support the web crypto API, while version 15 did not (version 11.6 below):

Edge

All Edge versions support the web crypto API. No screenshots were collected.

Android

The oldest version at our disposal was Android 4.4 which already did support the web crypto API.

iOS

Version 7 (left) did support the web crypto API, while version 4.3.2 did not (right):

Windows Phone

The only version at our disposal was Windows Phone version 8.1 which did support the web crypto API (below):

Sailfish OS

All Nightly browser versions support the web crypto API. No screenshots were collected.

Release v1.2 - QR codes, inline media display, 6 new languages & JS refactoring

2018-07-22T11:21:00+02:00

This release adds QR code generation, inline display of video, audio, PDF and new translations to PrivateBin and a large refactoring of the JavaScript code.

A new button lets you generate a QR code of your newly created pastes URL. This allows for easy transfer of a pasted data from one mobile device to another.

When the optional file upload is enabled, uploaded videos, audio files and PDFs are displayed inline, like we did with images, as long as the visitors browser supports it. By default the file and paste upload is limited to a 2 MiB size.

Translations for Spanish, Occitan, Norwegian, Portuguese, Dutch and Hungarian have also been added since the last release.

The main change of this release, and the reason it took us so long since doing the last one, was the large refactoring and cleanup of the JavaScript logic of PrivateBin. The refactoring itself was done in early 2017. In parallel we introced mocha and JSverify running on nodeJS as a property based unit testing framework for the logic (à la QuickCheck). Many months were spent to cover more and more pieces of the logic.

In the end we covered all of the modular parts of the logic (879 of 1273 lines of code for a 69% code coverage), including the encryption wrapper functions for backward compatibility with older paste formats. The UI related parts of the code proved difficult to test, partly because in nodeJS the browsers document object model (DOM) is emulated using the JSdom library, the lack of an actual view port being present (so no scrolling, for example) and also due the event driven nature which contradicts the modular approach of unit testing. For many UI interfaces, large parts of the DOM has to be present, since emitting a single click event may trigger changes in many different parts of the UI. This is a shortcoming of the current structure of the UI logic, which we may need to improve further.

Still, the unit testing found many regressions and some issues that have been in the code for a long time without having been reported. It lays the necessary ground work for the future changes, especially the major changes planned for the encryption format.

Benefits of switching to the new release

Apart from the new QR code feature many new translations were added. All used libraries were upgraded, too. While no security issues were reported for any of these, they address some bugs that didn't affect us directly or improve compatibility with the latests browsers and PHP releases.

Update procedure

A new configuration option name was introduced for those admins that like to replace the "PrivateBin" moniker in the template with their own site name.

As usual, you can download the archive for a manual upgrade and can find more details in the installation instructions.

We now also offer a Docker container that includes the recommended secure setup with the non-essential files and data outside of the web servers document root. We also started providing additional tools in Docker containers.

Changes since version 1.1.1

ADDED: Translations for Spanish, Occitan, Norwegian, Portuguese, Dutch and Hungarian
ADDED: Option in configuration to change the default "PrivateBin" title of the site
ADDED: Added display of video, audio & PDF, drag & drop, preview of attachments (#182)
ADDED: QR code generation (#169)
ADDED: Introduced DOMpurify library to sanitize generated HTML before display (#183)
CHANGED: Force JSON request for getting paste data & password retry (#216)
CHANGED: Minimum required PHP version is 5.4 (#186)
CHANGED: Shipped .htaccess files were updated for Apache 2.4 (#192)
CHANGED: Cleanup of bootstrap template variants and moved icons to img directory
CHANGED: Removed option to hide clone button on expiring pastes, since this requires reading the paste for rendering the template, which leaks information on the pastes state
CHANGED: Upgrading libraries to: SJCL 1.0.7, jQuery 3.3.1, Base64 2.4.5, Showdown 1.8.6, DOMpurify 1.0.5 & Prettify 453bd5f
CHANGED: Refactored JavaScript code, making it modular with private and public functions, making it much easier to maintain (#178)
FIXED: To counteract regressions introduced by the refactoring, we finally introduced property based unit testing for the JavaScript code, this caught several regressions, but also some very old bugs not found so far (#32)

Help wanted & greatly appreciated

Over the last months we often had issues to motivate ourselves to move on with the rather tedious refactoring and unit testing. As an open source project every contribution small or large is greatly appreciated. Especially all the new languages that got added show the core team that this project is used and how far it already got spread.

If you are interested in helping with any of these points, we have prepared a development guide including design goals, code structure and tools that should get you started.

Plans for future releases

In the next major release we plan to change the paste format. This includes introducing a new version identifier, support for different encryption schemes, ideally including the browsers internal cryptography instead of the JavaScript SJCL one, switch to a correct deflate compression implementation to ensure cross-language compatibility and generally review to paste format for improvements. Of course we will keep supporting both the original ZeroBin and current formats, so that upgrades remain possible without data loss. Thanks to the JavaScript unit testing introduced with this release, the backwards compatibility gets accounted for.

We also already have quite a few user interface improvements flagged for the release after that. We want to concentrate on the paste format first, to be able build on top of it. But we would of course not say no to any earlier pull requests for any of these.

All in all, with this tedious behind the scenes cleanup finally done, we now plan to return to a more frequent release cycle and wish you all,

Good night, and good luck.

Release v1.1.1 - Fix for data leak vulnerability

2017-10-10T20:57:00+02:00

This release fixes leakage of configuration and raw pastes that can occur in some setups.

On 29th of September, @pstn reported a medium data leak vulnerability in PrivateBin. If either a) a non-apache webserver is used or b) apache has "AllowOverride" disabled and the installation was not secured by changing the path of sensitive folders, these can be accessed from the outside. This release fixes this by converting these files from INI/JSON to php files, so that they are protected even under those conditions.

Further details on why this is an issue and its implications can be found in our report on the vulnerability. It also describes methods to check if your server is currently affected by the issue.

Benefits of switching to the new release

Even if you are currently using an apache server and are not affected by this issue, we would advise to plan to update soon. Some of the sites affected by this reported that they had changed their webserver setup, inadvertedly becoming affected. You might do the same in the future, too, and forget to check your PrivateBin setups security.

Alternatively consider to securing your installation by changing the path of folders containing sensitive information. We have updated our installation instructions, stressing our security recommendations.

Update procedure

Apart from updating the libraries and the javascript files, make sure that your PHP process can also write to the cfg folder. The next call to your privatebin installation will convert the conf.ini file into conf.php. Accessing pastes will convert these, too. Additionally we also are hooking into the purge mechanism to gradually convert pastes that are not frequently accessed.

Changes since version 1.1

CHANGED: Switched to .php file extension for configuration and data files, to avoid leaking data in unprotected installations.

Vulnerability Report

2017-10-10T20:29:00+02:00

On 29th of September 2017, @pstn reported a medium data leak vulnerability in PrivateBin. Vulnerability write-up done by @rugk and @elrido.
The vulnerability has been fixed in PrivateBin v1.1.1. Admins are urged to check whether they are affected by this configuration issue.

Affected versions

Any ZeroBin and PrivateBin version before 1.1.1

Conditions

Another web server than Apache has to be used or an Apache server with "AllowOverride None" option set for the virtualhost PrivateBin is hosted under.
The config and data directories are left in the websites document root path (contrary to the recommendation in the installation document).

Steps to reproduce configuration file leak

Go to https://paste.exmaple.com/cfg/conf.ini.
Download the file.

Steps to reproduce paste file leak

Go to https://paste.example.com/.
Create a new paste as usual via the UI.
Assuming the generated paste has been given the random ID fecba9876543210f, go to https://paste.example.com/data/fe/cb/fecba9876543210f.
Download the file.

Impact

In the circumstances described above, the config file of PrivateBin may have been leaked to third-parties. If a database is used, this includes the database passwords, which were set in the config file.

In reference to the Common Vulnerability Scoring System v3.0 we categorize this as a medium vulnerability. It can be exploited by remote attackers and it can leak confidential data (database passwords), so we consider it's confidentiality low, because it does not always leak such cinifdential data as passwords. In this calculator only the impact is considered, not the (special) condidtions, which we described above.

In setups using the file store instead of databases, the pastes are stored as text files containing raw JSON data structures under the data folder. The server side JSON contains some information that is not exposed to client via the REST API. Using the leaked paste salt and the already known paste ID one can generate a deletetoken using a SHA256 based HMAC function passing the pastes ID as the key and the salt as the message. This allows an attacker to delete any paste, if they know it's ID, even without any knowledge of the paste key or contents. While this does not stricly leak sensitive or encrypted data, it is contrary to the design of the software, that only intends to give the paste creator the ability to delete a paste before it times out. Thus this can be used to cause a kind of "denial of service" attack.

Real-life impact

Prior to releasing/fixing details of the vulnerability, we notified affected server admins, who (are listed on our wiki list).

We identified six affected servers affected by the config data leak. One of these servers also leaked MySQL credentials. We contacted these and provided information in order to fix the data leak.

Out of all contacted sites, four fixed the issue at the time of the publication of this advisory. The site which leaked MySQL credentials has fixed the issue and reported to have changed the credentials.

Mitigation

Since April 29th, 2012 (ba90d0c, while PrivateBin was still a fork of ZeroBin 0.15) we provided a way for server admins to secure their PrivateBin installation by moving important directories out of the web root. When a server admin has done so, they are not affected by this issue.

Secondly we always provided a .htaccess file, which automatically protected systems using the Apache server that do not disable the use of these.

System administrators can also always configure their own web server themselves to protect these special directories.

This vulnerability has been fixed in PrivateBin v1.1.1 released on 2017-10-10 with the commits 9215a96 and 6b87a6e. Additionally we changed our installation instructions to stress our security recommendations.

Further information

Administrators that are affected by this issue and saved confidential data (such as database passwords) in their config file, are strongly advised to change these credentials.

System administrators of the instances, where the cfg/ and data/ directory are accessible, should protect these directories with an appropriate web server configuration or by following these steps.

Timeline

2017-09-29 – Reporter asked for contact information, got a tip from collaborator.
2017-09-29 – Reporter privately reported issue.
2017-09-29 – Receipt confirmed.
2017-09-29 – Issue confirmed and preliminary patch provided to reporter.
2017-10-01 – Server admins contacted.
2017-10-04 – Restructured installation instructions.
2017-10-10 – Release published.
2017-10-10 – Vulnerability details published.

Release v1.1 - PrivateBin in Italian and Russian

2016-12-26T12:00:00+01:00

This release adds Italian and Russian translations to PrivateBin and fixes an XSS and a database issue.

Fortunately the CSP headers introduced in version 1.0 suppressed the XSS issue in modern browsers. But older browsers would still be affected when clicking on the "Raw text" button of a markdown formatted paste containing JavaScript. The issue was introduced with the change in version 1.0 that displays markdown code instead of the rendered HTML in the "raw" mode.

The other fixed issue concerns the automatic purging of outdated pastes, which was introduced in version 1.0. When using the database model instead of the default file based store, pastes set to "never" expire were always purged, too.

Benefits of switching to the new release

If you are using the database model instead of the filesystem one and offer pastes that "never" expire, then you should upgrade or disable the purge by setting the batchsize to 0 in your configuration.

Apart from fixing the XSS issue, markdown pastes containing HTML code will now be properly displayed in the "raw" mode.

Both of these issues affected only version 1.0. There are of course many more benefits in switching to this release, if you are still using a version of PrivateBin or ZeroBin before 1.0.

Update procedure

When updating please make sure to adjust the cspheader setting. We recommend you to either comment the setting out in order to use our default recommend CSP header or adjust the header so it matches the new default one (mainly just add the referrer no-referrer; part).

Changes since version 1.0

ADDED: Translations for Italian and Russian
ADDED: Loading message displayed until decryption succeeded for slower (in terms of CPU or network) systems
ADDED: Dockerfile for docker container creation
CHANGED: Using modal dialog to request password input instead of native JS input window (#69)
CHANGED: Suppressed referrer HTTP header sending when following links in a paste or comment (#96) and added additional HTTP headers for XSS mitigation (#91)
CHANGED: Updated random_compat and jQuery libraries
FIXED: XSS using JavaScript stored as markdown formatted paste, after clicking on Raw paste button (#137)
FIXED: Automatic purging deleting non-expiring pastes, when using database store (#149)

We wish you a happy new year!

Release v1.0 - The ZeroBin fork is now called PrivateBin

2016-08-25T11:50:00+02:00

This is the first release of PrivateBin after renaming the ZeroBin fork. We decided to use the version number 1.0 for this release as we consider PrivateBin now very mature and feature complete. We recommend everyone to update as this version features many security improvements.

The renaming of ZeroBin to PrivateBin is done to highlight the huge developments (over 500 commits) which have happened since ZeroBin stopped being actively maintained by its original creator Sébastien Sauvage in 2014. By choosing to release version 1.0 we also want to emphasize the many feature changes - according to semantic versioning - and want to show that PrivateBin is now considered mature. Hence a version number smaller than 1.0 just does not seem suitable for PrivateBin anymore.

Update procedure

Make sure your system has some source for cryptographically safe random numbers! Either use PHP 7 or one of the supported fallbacks: libsodium, open_basedir access to /dev/urandom, mcrypt or com_dotnet. The previous workaround using mt_rand() was removed, as it leads to unsafe and predictable numbers.

Otherwise, as usual, only the files need to be updated. The tmp folder for the compiled RainTPL templates can be removed, since we switched to a more lightweight template approach due to RainTPL not being maintained anymore. Have a look at or template documentation to learn how to upgrade your custom template to the new system.

There are some new options in the configuration file. If you are updating from an older ZeroBin install and want to keep existing pastes accessible, make sure to enable the option zerobincompatibility. Otherwise more secure settings are used which break compatibility with ZeroBin.

Benefits of switching to the new release

As a user of a ZeroBin instance nothing changes. As soon as the server administrator upgrades to PrivateBin, you can continue using it. We took great efforts to ensure that existing pastes are still fully compatible with the current release.

Since version 0.22 we added a Slowene and Chinese translation, an (optional) URL shortener button, a preview tab to help you chose the right format for your content and many other small user interface improvements to make your life a bit more comfortable.

With this release we have improved the security of PrivateBin as we have now addressed most concerns raised in a security audit of the original ZeroBin in 2014.

Furthermore we switched to AES Galois/Counter mode, which is considered a stronger encryption mode then the previously used AES Counter mode with CBC-MAC authentication. The main benefit here is that the authentication (as the pastes/comments are sent over network you want to ensure that your content is not accidentally or maliciously manipulated) is done on the encrypted text instead of the plain text. The potential parallelization of CCM could not be implemented in the single threaded Javascript environment of webbrowsers, anyway.

We also make use of a new browser security feature called Content Security Policy, which prevents XSS attacks in an effective way. It blocks any third party scripts and resources to be executed in the context of the application.

Additionally we started using the new subresource integrity (SRI) browser feature to avoid loading manipulated scripts under man-in-the-middle attacks. Additionally this allows privacy aware users to easily check for manipulated scripts in the source code of the website and to compare them to the hashes of the official PrivateBin release of that version.

To ensure that PrivateBins code is of high quality we added various code quality checkers and subsequently improved the code. These analysers also helped us to find some potential vulnerabilities.

If you have further questions or issues have a look at the new FAQ.

Changes since version 0.22

ADDED: Translations for Slowene and Chinese
ADDED: re-introduced (optional) URL shortener support, which was removed back in version 0.16 for privacy concerns
ADDED: Preview tab, helpful for writing markdown code or check the source code rendering
ADDED: Automatic purging of expired pastes, done on paste creation
ADDED: Option to disable icons in discussions (will only affect newly created pastes)
ADDED: Composer support
CHANGED: Renamed the ZeroBin fork to PrivateBin
CHANGED: Removed unmaintained RainTPL template engine, replacing the templates with straight forward PHP files
CHANGED: New logo and favicons
CHANGED: Upgrading SJCL library to 1.0.4
CHANGED: Switched to GCM instead of CCM mode for AES encryption for newly created pastes
CHANGED: Use backported random bytes function from PHP7 for older PHP versions instead of mcrypt
CHANGED: Switched to a SHA256 HMAC of the IP in traffic limiter instead of storing it in plain text on the server
CHANGED: Introduced content security policy header to reduce cross site scripting (XSS) risks
CHANGED: Added SHA512 subresource integrity hashes for all javascript includes to reduce the risk of manipulated scripts and easier detection of such
CHANGED: Refactored PHP code to conform to PSR-4 and PSR-2 standards
CHANGED: Switched to Identicons as the default for comments with nicknames
CHANGED: Vizhash is now optional and based on (128 byte) SHA512 HMAC instead of (144 byte) combination of MD5, SHA1 and a reversal of that string
FIXED: Content-type negociation for HTML in certain uncommon browser configurations
FIXED: JavaScript error displayed before page is loaded or during attachment load
FIXED: Don't strip space characters at beginning or end of optional password
FIXED: Various UI glitches in mobile version or on smaller desktops with language menu, button spacing and long URLs
FIXED: Back button now works as expected after switching to raw text view of a paste
FIXED: Reactivated second error message above send comment button to ensure its visibility when the main error message is outside the viewport
FIXED: Raw text now displays original markdown instead of rendered HTML
FIXED: Removed unused code detected with the help of various code review tools
FIXED: Table format for PostgreSQL, making it possible to use PostgreSQL as backend in addition to MySQL, SQLite and flat files

We hope you will enjoy the new PrivateBin!

Measures taken after the 2014 ZeroBin security audit

2016-08-24T19:23:00+02:00

Back on February 2nd, 2014 Taylor Hornby kindly performed a security audit of ZeroBin "for free as a service to the free/opensource community".

Some of the issues brought up were already fixed in 2014 by Sébastien Sauvage. Before releasing a stable version of the PrivateBin fork, we wanted to make sure to address all remaining issues as best as we could. Here is an overview over each point and the measures taken on them.

2.1. Salt and HMAC Key Generated with mt_rand()

Exploitability: Medium
Security Impact: Low

In serversalt.php, generateRandomSalt() generates a salt using the mt_rand() pseudo-random number generator. Because mt_rand() is not a cryptographic random number generator, this function will return easily-guessed salts with a much higher probability of collision.

The salts generated by this function are relied on for security. For example, it is used as an HMAC key when checking delete tokens in processPasteDelete(). It should be replaced with mcrypt_create_iv() or openssl_random_pseudo_bytes().

Four days after the release of the audit, Seb fixed this by using the mcrypt extension instead, if present. mt_rand was still in use as a fallback until and including version 0.22 of the ZeroBin fork.

For the upcoming release we decided to remove the fallback to mt_rand() completly and switch to PHP 7's random_bytes() instead, providing a couple of fallbacks for older PHP versions by using the random_compat library. With this change, the following sources of cryptographically safe random numbers are used in the following priority:

PHP 7's random_bytes()
libsodium
/dev/urandom
mcrypt
com_dotnet

More information about the order and reasons for this can be found in the official documentation.

We consider this point resolved.

2.2 Fixed Server Salt

Exploitability: Low
Security Impact: Low

The security of the VizHash hashes of IP addresses (used to generate comment avatars) and delete tokens both rely on a fixed "salt" which is generated once per deployment, saved in data/salt.php.

We switched to creating a salt per paste, which is used to create the delete tokens.

Using a paste specific salt for the VizHashes in comments with nicknames would make it impossible to recognize the same IP accross pastes and therefore make the use of VizHashes moot.

We consider this point solved for the delete tokens. Regarding the VizHashes, server admins now have the option to disable icons in the configuration file to avoid this risk and users can simply choose to comment anonymously without nickname.

All in all we consider this point partly resolved. We provided reasonable configuration options for admins wanting to enhance the security of their PrivateBin instance.

2.3. Traffic Limiter Race Conditions

To rate limit requests, ZeroBin keeps a history of hit times in data/traffic_limiter.php, which is generated and re-generated in traffic_limiter_canPass(). Because requests can be made asynchronously, the file may become corrupted.

This might allow remote code execution, if the attacker is clever enough to corrupt the file in just the right way, since the traffic_limiter.php file is require()'d.

Although the patch for this was already sent in at September 28th, 2013, the pull request was only merged a day after the release of the security audit.

We consider this point resolved.

2.4. VizHash IP Address Online Guessing

Exploitability: Very Low
Security Impact: Low

The VizHash system is used to give users who comment an avatar derived from their IP address. If an attacker can create connections to the ZeroBin server from arbitrary source IPs (e.g. if they are in the same LAN as the ZeroBin server, or man-in-the-middling its traffic), they can perform an online guessing attack on the VizHash they are interested in.

As explained above this is an inherant problem of using IP based icons. Apart from the option to disable icons in the configuration file to avoid this risk for server admin and the option for users to simply not comment with a nickname, we also switched to using a SHA512 HMAC instead of the odd combination of MD5, SHA1 and a reversal of these that was used in VizHash originally.

We consider to have reduced the risk of this point and given options to both server admins and users to avoid it completly. We could disable icons by default, to solve it permanently.

2.5. Relies on .htaccess files, which may not be enabled.

Exploitability: N/A
Security Impact: Very Low

ZeroBin relies on .htaccess files being enabled to prevent access to the 'data' directory. This directory contains the ciphertexts, salt, and rate limiter array. If .htaccess is disabled, of if ZeroBin is installed on a non-Apache web server, then an attacker may be able to access these files.

Back in 2015 we implemented an option that allows server admins to install most sensitive parts of the application outside of the webservers document root. This is explained in the installation documentation. The .htaccess files are still generated to protect lazy server admins that use an Apache webserver.

We consider this point resolved.

2.6. The robots.txt does not work in a subdomain.

Exploitability: N/A
Security Impact: Low

ZeroBin uses a robots.txt file to prevent search engines from indexing the posts. If you install ZeroBin into a subdirectory, this does not work.

We added a section to the installation documentation to remind server admins to change the file if PrivateBin runs in a subdirectory.

We consider this point resolved.

2.7 HMAC Not Compared in Constant Time

Exploitability: Medium
Security Impact: Low

ZeroBin uses an HMAC to generate and check delete tokens. The HMAC is compared against the correct one with PHP's "!=" operator. A timing attack can exploit this error to compute the HMAC of arbitrary data with the server's salt.

Seb implemented the suggested slow_equals() function on February 6th, 2014.

We consider this point resolved.

2.8. Arbitrary File Unlink

Exploitability: Medium
Security Impact: High

An attacker can delete arbitrary files on the server by exploiting a vulnerability in processPasteDelete().

This was addressed in the same cherry picked and merged commit in August 15th, 2015 that mainly addressed 2.7 above. Not only is the paste ID now checked for general format validity (16 hexadecimal characters), but also if that paste actually exists.

We consider this point resolved.

2.9. HMAC Uses SHA1 instead of SHA256

Exploitability: Very Low
Security Impact: Low

ZeroBin uses a SHA1 HMAC to derive the delete token. SHA1 should be replaced with a better hash function, like SHA256.

This was addressed in a commit on July 6th, 2016. As this is a breaking change (it means that old deletion links will no longer work) it is enabled by default, but for admins upgrading from older installs there is an option zerobincompatibility to return to the old behaviour.

We consider this point resolved.

2.10. No Cross-Site Request Forgery Protection

Exploitability: Medium
Security Impact: Medium

ZeroBin does not attempt to prevent Cross-Site Request Forgery (CSRF) attacks. A malicious website can make a user's browser delete ZeroBin posts (if the delete token is known), create posts, and post comments to existing posts.

Due to the nature of PrivateBin it is inherently possible to create pastes and comments anonymously. Hence we can't just introduce a user account system or API tokens. As we plan to allow alternative clients to use existing PrivateBin instances adding a CORS or CSP header to disallow external sources to access the API would not work either.

We consider this an ongoing design challenge and still keep an open issue on this point.

3.1. Always Assume Malice

When a string is used in a way that might affect security, it should always be assumed to be malicious, even if it is just a constant string.

All the mentioned examples were escaped and/or reinforced with checks. Unit testing was used to ensure that these filtering functions aren't weakened in some later regression.

This danger also applies for any newly created template. We addressed this with a reminder on escaping in the template creation documentation.

We consider this point resolved.

4.1. Secure Code Delivery

ZeroBin relies on the JavaScript code being delivered securely. A malicious server or man-in-the-middle can modify the code to leak the key. This is already well known and is being addressed in GH17.

The method using a JS snipped to validate hashes of the JS code was never implemented. We did instead implement subresource integrity (SRI) hashes on August 16th, 2016. Combined with content security policy (CSP) headers, this limits the attack surface to man-in-the-middle attacks on the index.html file and rogue server admins.

Server admins can reduce the potential for man-in-the-middle attacks by setting up HTTPS following high standards. We documented this in the main README.md of the project and also added some recommendations on how to set up HTTPS more securely.

For users we provide recommendations how they can find the best servers.

But as long as the encryption logic is delivered by the server, the risk of manipulation is always a possibility. This is not fixable and therefore users have to trust the webserver running PrivateBin. We try to make PrivateBin users aware of this by e.g. stating it in our Readme.

We consider this issue unsolvable within the scope of the project.

4.2. urls2links XSS

In zerobin.js, urls2links() converts a URL text into a clickable link. The replacement is done purely by regular expression, and no escaping is done. This may be a source of XSS vulnerabilities.

Only URLs starting with the schemas http, https, ftp and magnet are converted. Also no characters outside A-Z, a-z, 0-9 and the following ones are allowed: ? = & . \ / - ; # @ ~ % + -

We tried to find better tested implementations, but they ended up being less restrictive on the allowed schemas. So far we could not find a way to inject any executable code, but that is no proof that there isn't.

We consider this a risky piece of code.

4.3. Low Entropy in Browsers Without CSPRNGs

If the web browser does not have window.crypto.getRandomValues(), the key is derived from mouse movements and stuff. That may not be good enough. Perhaps in these cases the server could help the client by supplying some of its own entropy from mcrypt_create_iv() or openssl_random_pseudo_bytes().

We ignored this issue so far, as it affects mostly older platforms.

4.4. Plaintext is Compressed Before Encryption

Posts are compressed before they are encrypted. This makes the ciphertext length depend on the plaintext content. This may create vulnerabilities in specific use cases where an attacker can choose variations of the same post to be encrypted. This would be similar to the CRIME and BREACH attacks, except happening at the application layer.

We don't think this is applicable in our case, as even when generating many pastes with variations of the same content, they would also all get encrypted with different keys. But an issue was created to implement an option that would allow server admins to disable compression.

We ignored this issue so far.

4.5. Is SJCL used correctly?

This audit did not check if zerobin.js uses the SJCL cryptography library correctly.

The implementation follows the examples of the SJCL librarys homepage and its API documentation. We tried to harden its usage further by explicitly passing encryption options on mode, key size and authentication tag size instead of using the defaults.

We consider this point resolved.

4.6. Possible XSS in tpl/page.html

JSON encoded data is inserted into the HTML page unescaped in tpl/page.html. This is because $STATUS is set to the return value of processPasteFetch(), which returns JSON encoded data based on the user's input.

In the current templates, this and the other variables are encoded/escaped before insertion. As mentioned in point 3.1 this needs to be rechecked for every newly created template.

We consider this point resolved.

Summary

We think that what we are left with are two issues that pose larger design challenges or we consider unsolvable in the scope of the project, two issues we ignored as they do not seem to apply to our case or only affect older platforms and for one issue we haven't yet found a better solution short of removing the feature.

All in all we are confident that most points of this audit could be resolved and are ready for a stable release and future audits.

Welcome to our new project page

2016-08-16T20:42:00+02:00

In preparation of the upcoming first release of the ZeroBin fork under the new name, we have set up this little project website. Its intended to be updated mostly with release announcements and some intermediate updates such as this one.

The release has now all the features we thought necessary to include. Currently we are in some final testing rounds and plan to have a the release ready before the end of August.

Cheers,
El RIDO