DokuWiki: Recently Opened Tasks

[issue-open]: Extension plugin: list without using remote repository

iainhallam — Thu, 13 Aug 2026 09:53:14 +0000

When I list the plugins installed on my DokuWiki instances, I often don't care whether updates are available, so I'd like to add an option to the CLI command `plugin.php extension list` to not contact the remote server to reduce time and traffic.

I was thinking `-n` and `--no-remote`, or `-o` and `--offline`, but anything sensible would work.

[issue-open]: do=debug - code in html.php ($conf array copy before debug_guard) causes AuthAD failure

stracfor — Wed, 12 Aug 2026 14:43:04 +0000

## The problem

### Browser (Client) shows
[...]
Auth backend capabilities:

TypeError: Cannot access offset of type string on string
An unforeseen error has occured. This is most likely a bug somewhere. It might be a problem in the authad plugin.
More info has been written to the DokuWiki error log.

### DokuWiki error log
2026-08-12 14:53:06TypeError: Cannot access offset of type string on string C:\inetpub\wwwroot\dokuwiki\lib\plugins\authad\auth.php(697)
#0 C:\inetpub\wwwroot\dokuwiki\lib\plugins\authad\auth.php(143): auth_plugin_authad->loadServerConfig()
#1 C:\inetpub\wwwroot\dokuwiki\inc\html.php(777): auth_plugin_authad->canDo()
#2 C:\inetpub\wwwroot\dokuwiki\doku.php(105): html_debug()
#3 {main}

### Solution / Bugfix
\inc\html.php - change line 728 (dokuwiki-2026-07-14a_Mort)
from:

$cnf = $conf;

to

$cnf = unserialize(serialize($conf));

and do the same for the following arrays changing:
(This is not needed to solve the do=debug/AuthAD issue but I would recommend this to avoid future issues.)

$nfo = $INFO;
$ses = $_SESSION;

to

$nfo = unserialize(serialize($INFO));
$ses = unserialize(serialize($_SESSION;));

before calling function debug_guard

## Used versions

### Version of DokuWiki

2025-05-14b "Librarian"

### PHP Version

8.5.7

### Webserver and version of webserver

IIS (Windows Server 2019)

### Browser and version of browser, operating system running browser

Chrome 151.0.7922.109

## Additional environment information

### Working fine (no issue) are

- regular operation
- do=check

### Evidence
#### Content of $conf
**inc\html.php – add $conf in addition to $cnf**

echo '$cnf:

';
    print_r($cnf);
    echo '

';

echo '$conf:

';
    print_r($conf);
    echo '

';

**Result:**
$cnf and $conf are both containing the same information for $conf[‘plugin’][‘authad’]
[authad] => ***
=> $conf is owerwritten for key $conf['plugin']['authad'], the rest is as expected / no furhter issues are present

### Root cause analysis
#### Summary
Issue caused by References in array $conf[]

#### Number of References – debug_zval_dump($conf);
**inc\html.php** – add debug output at line 728 in function html_debug() (dokuwiki-2026-07-14a 'Mort')

ob_start();
debug_zval_dump($conf);
$dump = ob_get_clean();

error_log($dump);

**Result: (php_errors.log)** - debug_zval_dump is showing references within the $conf array, most with refcount(1) as in

["authldap"]=>
array(1) refcount(1){
["server"]=>
[…]
}
however for **["authad"] refcount(2)**:

["authad"]=>
reference refcount(2) {
[…]
}

#### Bugfix as known solution for refenence in array issue

$cnf = $conf; // creates only a shallow copy - references in array are copied !!!
$cnf = unserialize(serialize($conf)); // creates a deep copy

Proof: deep copy solves the issue.

#### PHP copy of variable
According to PHP documentation copying a variable (array) will copy references in arrays as well.
This is the case for the mentioned line for bugfixing:

$cnf = $conf;

**\lib\plugins\authad\auth.php** - line 87 (dokuwiki-2026-07-14a 'Mort')

// we load the config early to modify it a bit here
$this->loadConfig();

Number of References
before call of loadConfig:
["authad"]=>
array(17) refcount(1){
after call of loadConfig:
["authad"]=>
reference refcount(2) {

\inc\Extension\PluginTrait.php - line 218 (dokuwiki-2026-07-14a 'Mort')

public function loadConfig()
{
[...]
$this->conf =& $conf['plugin'][$plugin]; // Here the reference is created by '=&'

### Why is =& no a bug?
=& is neede to write content to $conf by use of object property as in line 91 and following:
$this->conf['additional'] = str_replace(' ', '', $this->conf['additional']);
In my oppinion this is ok / a smart approach.
An alternative solution would be to implement a function similar to getConf named writeConf.
The use of this function in auth.php however will not simplify the code.
In addition the proposed solution is not creating any delay to regular operation which could be the case for any alternative solutions in AuthAD / the plugins.

### DokuWiki latest version 'Mort'
According to my check in the source code the issue should be present in latest version as well.

### Relevant logs and/or error messages

```text
Please check the information given above!
```
File to reproduce issue & created output:

[bug-reproduction.php](https://github.com/user-attachments/files/31020202/bug-reproduction.php)

[bug-reproduction_output.txt](https://github.com/user-attachments/files/31020230/bug-reproduction_output.txt)

[issue-open]: disableactions bypass

splitbrain — Mon, 10 Aug 2026 18:49:38 +0000

Reported by email. The reporter wishes to stay anonymous.

It is possible to bypass some of the actions disabled through $conf["disableactions"] by prepending and/or appending underscores to the action name.

How to reproduce:

* Set $conf["disableactions"] = "media";
* Access a wiki page using ?do=media_ (or even ?do=_media__foo_bar___)
* Expected result: Either "Action disabled: media" or "Unknown action: media_".
* Actual result: The media library is shown.

I do not understand the code well enough to see why this happens.

The ActionRouter constructor cleans the action name with act_clean(), but this preserves underscores since that's in use by export_html and others. The setupAction method then checks if "media_" is disabled, which it is not (it's not in $this->disabled), to the processing continues. When loadAction runs, it removes underscores from the action name when looking up the class name, and ends up resolving the action to 'dokuwiki\\Action\\Media', and runs the code in inc/Action/Media.php, which I would expect it not to do.

This way of bypassing $conf["disableactions"] does not work for all actions, I see that some actions explicitly check if the operation should proceed by calling actionOK() with a constant parameter, for example inc/Action/Register.php:

if (!actionOK('register')) throw new ActionDisabledException();

But the classes that don't do this extra check (inc/Action/Media.php seems to be one of those), seem to be vulnerable.

From the documentation on https://www.dokuwiki.org/devel:action_router it looks like the ActionRouter is responsible for checking the action against the disableactions setting, and that each class should not be required to do the extra actionOK() check.

[issue-open]: Should $updateVersion be updated in master?

fiwswe — Sun, 09 Aug 2026 21:29:49 +0000

Not sure if this a bug or not?

I have Git 2026-07-25 (150329c0dc8e5841ec440422331d3ab6da78fdec) (`master`) installed for testing and it shows the notification:
`Hotfix release available: 2026-07-14a "Mort". upgrade now! [57.1] (what's this?)`

However _upgrading_ `master` to 2026-07-14a "Mort", an older version, makes no sense and might even be harmful.

Should `$updateVersion` be updated to to the latest release version in master when a new release is published? In this case that would be to `$updateVersion = "57.1";`.
https://github.com/dokuwiki/dokuwiki/blob/150329c0dc8e5841ec440422331d3ab6da78fdec/doku.php#L16

[issue-open]: CSS: and `copy button should not move when scrolling content`


schplurtz — Sun, 09 Aug 2026 09:33:37 +0000
### The problem

Hi,

When content of `` and `` block is very large, one can horizontally scroll the content. The copy-to-clipboard button should stay in the upper right corner but instead it scrolls with the content. Eventually, it will leave the viewbox.

I expect the copy button to stay in the upper right corner.

How to recreate:

Add this wiki code in a page, save, then scroll horizontally.
```

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

```


### Version of DokuWiki

Mort

### PHP Version

NA

### Webserver and version of webserver

NA

### Browser and version of browser, operating system running browser

NA

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```



[issue-open]: List handling in mixed dw+md or md+dw mode
tkilla77 — Thu, 06 Aug 2026 14:08:14 +0000
### The problem

List handling in mixed (md+dw and dw+md) modes could be relaxed a bit.

Steps:
- select dw+md mode
- have a page with non-indented lists such as:

```
* item 1
* item 2

1. item
2. item

```
- expected: snippet is rendered as a bulleted (ul) and numbered (ol) list
- actual: snippet is rendered as regular text

Rationale: dw+md mode will be the most common way to transition away from markdowku plugin. Using md+dw mode would not support dw-style numbered lists, since the dash is understandably interpreted as regular bullet. However, markdowku did support non-indented lists.





### Version of DokuWiki

2026-07-14a "Mort"

### PHP Version

8.4

### Webserver and version of webserver

_No response_

### Browser and version of browser, operating system running browser

_No response_

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```


[issue-open]: Code block yaml syntax highlight seems to be buggy
Kurgan- — Thu, 06 Aug 2026 11:27:33 +0000
### The problem

I have created some pages on my wiki where I show yaml file examples (for Crowdsec), and it seems to me that yaml syntax highlighting has issues with some character sequences. 

Here is an example that fails to highlight properly:

```
onsuccess: next_stage
#debug: true
filter: "evt.Parsed.program == 'exim'"
name: kurgan/exim-logs
description: "Parse exim logs"
pattern_syntax:
  NO_DOUBLE_QUOTE: '[^"]+'
  NO_END_BRACKET: '[^\]]+'
```
In this example, the row  `NO_DOUBLE_QUOTE: '[^"]+'` fails to parse correctly at the `"` character, then the rest is not parsed anymore.

You can see it in action here: https://kb.kurgan.org/crowdsec:crowdsec-exim



### Version of DokuWiki

2026-07-14a "Mort"

### PHP Version

8.3.32

### Webserver and version of webserver

Apache 2.4 on Debian

### Browser and version of browser, operating system running browser

Firefox 153 on Linux

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```


[issue-open]: italic text ending with : is most times not recognized
Klap-in — Tue, 04 Aug 2026 21:42:22 +0000
### The problem

```
//Note://

//ItalicNote:// text //ItalicNote without colon//

//NoItalicNote:// text //NoItalicNote with colon://
```
This italic _Note:_ is not recognized due to the `:` before the closing `//`. e.g `//Note:h//` works.
It works if after the italic note which includes a colon, there follows in that paragraph another italic text without colon before the closing tag.

Just guessing: is it eventually related to link syntax?

I suppose it was working before the recent refactoring of the parser, as on _devel:unittesting_ wiki page it was used several times.

### Version of DokuWiki

git master

### PHP Version

8.2

### Webserver and version of webserver

Apache on Ubuntu

### Browser and version of browser, operating system running browser

Chrome on Ubuntu 24.04

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```
[Edit: corrected semicolon in colon]


[issue-open]: Release zip's contain .git directory
sigio — Fri, 31 Jul 2026 12:00:33 +0000
I noticed that the github releases (zip/tarfiles) contain the .git directory.
If, following the upgrade/setup instructions, these are unpacked in the webroot, the .git folder wil be available online.

While this isn't really a problem, scanning services like Shadowserver trigger warnings on this (and then mail abuse-departments at hosters).

I recently upgraded to 2026-07-14a, and then got one of those abuse mails today. It took a while to find out why this was triggered, but it seems that they alert on retrieving .git/config on any webhost/ip.

We could probably cleanup the .git folder on release zips ... as these don't need to be available for users just running released versions.

I looked into the package workflow, but didn't see a quick way to rectify this, so no patch / PR yet.


[issue-open]: TypeError gotcha for missing config value
winks — Wed, 29 Jul 2026 14:31:37 +0000
### The problem

I have a very old dokuwiki install with a custom local config, where `$conf['syntax']` was never configured.

When upgrading to 2026-07-14a Mort today I got this:

```
TypeError: dokuwiki\Parsing\ModeRegistry::__construct(): Argument #1 ($syntax) must be of type string, null given, called in .../public/inc/parserutils.php on line 239
```

Which is fine and easy to fix, but looking at this line 239 (and surrounding):

https://github.com/dokuwiki/dokuwiki/blob/master/inc/parserutils.php#L239

```
function p_get_instructions($text, $syntax = null)
{
    global $conf;

    $registry = new ModeRegistry($syntax ?? $conf['syntax']);
```

I mean I'm not saying it's wrong but `$syntax` would be null and then although it matches the type hint in the comment it still falls on its face.

Maybe no `$conf['syntax']` is a lesser known edge case with my 

```
define('DOKU_CONF', __DIR__ . '/../../conf');
```

So maybe it would just be a good idea to mention this again in the upgrade doc, although I honestly don't remember if this was an official method of having several wikis or if it was just some hack :)

And yes, I'm gonna sync my dokuwiki.php in the DOKU_CONF dir now because not overwriting this is the main problem I guess, so possibly more of an FYI than a bug.

Thanks for continued updates!

### Version of DokuWiki

2026-07-14a Mort

### PHP Version

8.4

### Webserver and version of webserver

_No response_

### Browser and version of browser, operating system running browser

_No response_

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```


[issue-open]: Mangled emails in diff dropdowns
annda — Wed, 29 Jul 2026 11:17:49 +0000
### The problem

When a wiki is configured to show editors as email, the revision dropdowns on the diff page show mangled email as double-encoded HTML entities instead of the address, e.g.:

```
16.07.2026 10:39 admin@ola...
```

**Relevant config**:`showuseras = email` or `email_link`, and `mailguard = hex` (default)

Diff dropdowns show broken obfuscated emails.

This is probably caused by `editorinfo()`/`userlink()` (`inc/common.php`) not honoring `$textonly` for the emails, combined with `inc/Ui/PageDiff.php::buildRevisionOptions()` escaping the result again.

### Version of DokuWiki

2026-07-14a "Mort"

### PHP Version

8.5

### Webserver and version of webserver

Nginx

### Browser and version of browser, operating system running browser

any

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```


[issue-open]: SSRF via RSS Feed Parser — No Internal IP Filtering (CWE-918)
javokhir-sec — Tue, 28 Jul 2026 17:58:04 +0000
## Summary
The `{{rss>URL}}` wiki syntax triggers server-side HTTP requests without any IP validation. Attackers can access internal services and cloud metadata endpoints.

## Details
- **Files:** inc/Parsing/ParserMode/Rss.php, inc/Feed/FeedParserFile.php, inc/HTTP/HTTPClient.php
- **Auth:** AUTH_EDIT (any user with edit permission)
- **CWE:** CWE-918 (Server-Side Request Forgery)
- **CVSS Estimate:** 8.8

The `HTTPClient` class has NO protection against:
- Loopback (127.0.0.1)
- Private IPs (10.x, 172.16-31.x, 192.168.x)
- Cloud metadata endpoints (169.254.169.254)

## PoC
1. Edit any wiki page
2. Insert: `{{rss>http://169.254.169.254/latest/meta-data/}}`
3. Save — server fetches the URL on page render

## Impact
- Access cloud metadata (AWS, GCP, Azure)
- Port scan internal network
- Access internal services (Redis, Elasticsearch, databases)

## Fix
Add IP validation in HTTPClient to block private/loopback/link-local IP ranges before making requests.

## Additional Findings
Two more vulnerabilities found in the same codebase:
1. **CSRF on User Registration** (CVSS 8.0) — `register()` in inc/auth.php doesn't call `checkSecurityToken()`
2. **SVG XSS via Weak Content Check** (CVSS 7.6) — Only checks first 256 bytes and doesn't validate SVG properly

## Credits
Discovered by Javokhir Tursunboyev (@javokhir-sec) on 2026-07-28

---
*Reported per DokuWiki's SECURITY.md which accepts GitHub Issues for vulnerability reports.*


[issue-open]: Toolbar disappears
ul71rich — Mon, 27 Jul 2026 06:18:51 +0000
### The problem

After updating to DokuWiki 2026-07-14a the toolbar on top of the edit window disappears.

### Version of DokuWiki

DokuWiki 2026-07-14a

### PHP Version

8.4

### Webserver and version of webserver

Apache 2.4

### Browser and version of browser, operating system running browser

Firefox 153.0, Chrome 150.0.7871.186 on Windows 11 Pro 25H2

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```


[issue-open]: Please consider putting your wiki software on https://www.home-assistant.io/
robertsaron — Sat, 25 Jul 2026 06:50:22 +0000
Please consider putting your wiki software on https://www.home-assistant.io/ I have been through 3 wiki programs (dokuwiki being one of them), that say they support Home Assistant, and none of them work the way they should.  Only one of them supports Ingress with Home Assistant.

DokuWiki: Recently Opened Tasks

[issue-open]: Extension plugin: list without using remote repository

[issue-open]: do=debug - code in html.php ($conf array copy before debug_guard) causes AuthAD failure

[issue-open]: disableactions bypass

[issue-open]: Should $updateVersion be updated in master?

[issue-open]: CSS: and copy button should not move when scrolling content

[issue-open]: List handling in mixed dw+md or md+dw mode

[issue-open]: Code block yaml syntax highlight seems to be buggy

[issue-open]: italic text ending with : is most times not recognized

[issue-open]: Release zip's contain .git directory

[issue-open]: TypeError gotcha for missing config value

[issue-open]: Mangled emails in diff dropdowns

[issue-open]: SSRF via RSS Feed Parser — No Internal IP Filtering (CWE-918)

[issue-open]: Toolbar disappears

[issue-open]: Please consider putting your wiki software on https://www.home-assistant.io/

[issue-open]: CSS: and `copy button should not move when scrolling content`