Security Advisories (1)
CVE-2026-15689 (2026-08-15)

Dancer2::Plugin::Auth::Extensible versions through 0.713 for Perl allow password reset link poisoning via the request Host header in _default_email_password_reset and _default_welcome_send. Both default emails emit a link of the form `$base/login/$code`, whose authority comes from the request Host header, or from X-Forwarded-Host under behind_proxy (obtained from Dancer2's request->base function). A POST to /login carrying submit_reset and a username needs no authentication: it stores a fresh reset code against that account and mails the account holder a link to a host of the sender's choosing. The welcome mail takes the same path when the application calls create_user with email_welcome set. Through 0.711 the handlers read `request->uri_base` and `request->base` directly; Versions 0.712 and later provide an uri_base configuration key that defaults to the untrusted `request->uri_base` when unset. The default configuration with reset_password_handler enabled and the default message text, a recipient who follows the link hands a working reset code to the sender's host, which is enough to take over the account.

NAME

Dancer2::Plugin::Auth::Extensible::Provider::Config - example auth provider using app config

DESCRIPTION

This is a simple authentication provider which authenticates based on a list of usernames, passwords (crypted, preferably - see below) and role specifications provided in the realm definition in your app's config file.

This class is primarily intended as an example of what an authentication provider class should do; however, if you just want simple user authentication with user details stored in your app's config file, it may well suit your needs.

See Dancer2::Plugin::Auth::Extensible for details on how to use the authentication framework.

SYNOPSIS

In your app's config.yml:

plugins:
    Auth::Extensible:
        realms:
            config:
                provider: Config
                users:
                    - user: dave
                      pass: supersecret
                      roles:
                        - Developer
                        - Manager
                        - BeerDrinker
                    - user: bob
                      pass: '{SSHA}+2u1HpOU7ak6iBR6JlpICpAUvSpA/zBM'
                      roles:
                        - Tester

As you can see, you can define the usernames, passwords (please use crypted passwords, RFC2307-style, not plain text (although plain text *is* supported, but really not a good idea), and the roles for each user (if you're not planning to use roles, omit the roles section from each user entirely).

ATTRIBUTES

users

Array reference containing users from configuration.

METHODS

authenticate_user $username, $password

get_user_details $username

get_user_roles $username