[Bug]: IPv6 filters in flow cause excessive logging

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

When a flow has a 'Request remote address' 'does not match IPv6' rule and nextcloud is accessed via IPv4, the log becomes full with error messages.

Steps to reproduce

1. Add a 'Block access to a file' flow.
2. Add a 'Request remote address' 'does not match IPv6' rule to the flow.
3. Access nextcloud via IPv4.

Expected behavior

No excessive logging.

Nextcloud Server version

31

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Nginx

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "31.0.7.1",
        "overwrite.cli.url": "https:\/\/wolke.watuwe.org",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "timeout": 1.5,
            "read_timeout": 1.5
        },
        "maintenance_window_start": 100,
        "default_phone_region": "DE",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "sendmail",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "maintenance": false,
        "loglevel": 2,
        "logtimezone": "Europe\/Berlin",
        "default_timezone": "Europe\/Berlin",
        "default_language": "de",
        "default_locale": "de_DE",
        "simpleSignUpLink.shown": false,
        "theme": "",
        "files.chunked_upload.max_size": 20971520,
        "app_install_overwrite": []
    }
}

List of activated Apps

Enabled:
  - activity: 4.0.0
  - app_api: 5.0.2
  - bruteforcesettings: 4.0.0
  - calendar: 5.3.8
  - cloud_federation_api: 1.14.0
  - comments: 1.21.0
  - contacts: 7.2.3
  - dav: 1.33.0
  - federatedfilesharing: 1.21.0
  - files: 2.3.1
  - files_accesscontrol: 2.0.0
  - files_downloadlimit: 4.0.0
  - files_pdfviewer: 4.0.0
  - files_sharing: 1.23.1
  - files_trashbin: 1.21.0
  - files_versions: 1.24.0
  - fileslibreofficeedit: 2.0.1
  - logreader: 4.0.0
  - lookup_server_connector: 1.19.0
  - notifications: 4.0.0
  - oauth2: 1.19.1
  - password_policy: 3.0.0
  - privacy: 3.0.0
  - profile: 1.0.0
  - provisioning_api: 1.21.0
  - settings: 1.14.0
  - systemtags: 1.21.1
  - tables: 0.9.5
  - text: 5.0.0
  - theming: 2.6.1
  - twofactor_backupcodes: 1.20.0
  - viewer: 4.0.0
  - webhook_listeners: 1.2.0
  - workflowengine: 2.13.0
Disabled:
  - admin_audit: 1.21.0
  - circles: 31.0.0 (installed 28.0.0-dev)
  - contactsinteraction: 1.12.0 (installed 1.9.0)
  - dashboard: 7.11.0 (installed 7.8.0)
  - documentserver_community: 0.2.0 (installed 0.2.0)
  - encryption: 2.19.0
  - federation: 1.21.0 (installed 1.18.0)
  - files_external: 1.23.0
  - files_reminders: 1.4.0 (installed 1.1.0)
  - firstrunwizard: 4.0.0 (installed 2.17.0)
  - nextcloud_announcements: 3.0.0 (installed 1.17.0)
  - photos: 4.0.0 (installed 2.4.0)
  - recommendations: 4.0.0 (installed 2.0.0)
  - related_resources: 2.0.0 (installed 1.3.0)
  - serverinfo: 3.0.0 (installed 1.18.0)
  - sharebymail: 1.21.0 (installed 1.18.0)
  - support: 3.0.0 (installed 1.11.0)
  - survey_client: 3.0.0 (installed 1.16.0)
  - suspicious_login: 9.0.1
  - twofactor_nextcloud_notification: 5.0.0
  - twofactor_totp: 13.0.0-dev.0
  - updatenotification: 1.21.0 (installed 1.18.0)
  - user_ldap: 1.22.0
  - user_status: 1.11.0 (installed 1.8.1)
  - weather_status: 1.11.0 (installed 1.8.0)

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

unpack(): Type A: not enough input, need 16, have 4 at /var/www/nextcloud/apps/workflowengine/lib/Check/RequestRemoteAddress.php#115
Trying to access array offset on value of type bool at /var/www/nextcloud/apps/workflowengine/lib/Check/RequestRemoteAddress.php#116

Additional info

In https://github.com/nextcloud/server/blob/v31.0.7/apps/workflowengine/lib/Check/RequestRemoteAddress.php, the methods matchIPv6 and matchIPv4 don't check the address family of the address passed as argument. Adding a check between the two lines

https://github.com/nextcloud/server/blob/d4cede3cabe216ba90ea00bc261174c05f813ea4/apps/workflowengine/lib/Check/RequestRemoteAddress.php#L98-L99

in matchIPv6 and return false when it isn't an IPv6 address fixes this issue.

A bit unrelated to this I found that the code copied from stackoverflow for the ipv6ToBits method had an error. The unnecessary unpack will strip certain bytes from the end of IPv6 addresses that are considered 'whitespace' characters. So for example it will turn 2003::20:090d:0a00 into just 2003::. Meanwhile, the code in the stackoverflow answer has been fixed.

Start with apps/workflowengine/lib/Check/RequestRemoteAddress.php, especially matchIPv6, matchIPv4, and ipv6ToBits, and compare the reported log lines at 115–116 with the IPv4 and IPv6 reproduction steps. Done means IPv4 requests no longer produce unpack or array-offset errors for an IPv6 filter, while IPv6 addresses retain their full value during conversion.