Share via

.NET MAUI App: Stack canary protection not enabled

Srikanth 0 Reputation points
2026-02-13T07:47:09.4733333+00:00

We developed a .NET MAUI application, and our security team reported issue: “Stack canary not enabled.” We attempted to enable stack protection by adding flags such as -fstack-protector-strong, but the scanner result did not change.

What is the Microsoft-recommended way to verify whether stack canaries are enabled for a MAUI app?

If the scanner is producing a false positive, what is the best-practice approach to prove stack canaries are present (e.g., what commands/artifacts should we provide to our security team)?

Observations:

It appears some security scanners may not correctly recognize protections in .NET AOT binaries, potentially leading to false positives.

Related discussion: https://github.com/dotnet/runtime/issues/105101

OWASP MAS guidance we referenced (compiler optimizations / checks): https://mas.owasp.org/MASTG/tests/android/MASVS-CODE/MASTG-TEST-0223/

Stack Canary

Developer technologies | .NET | .NET MAUI
{count} votes

2 answers

Sort by: Most helpful
  1. Jack Dang (WICLOUD CORPORATION) 14,955 Reputation points Microsoft External Staff Moderator
    2026-02-13T10:23:38.1833333+00:00

    Hi @Srikanth ,

    Thanks for reaching out.

    Based on the official Microsoft documentation and community discussions, there isn't currently a straightforward way to verify traditional stack canaries in .NET MAUI AOT binaries because the Mono AOT compiler doesn't emit stack canaries in the same way native C/C++ compilers do. The .NET team acknowledged this in the issue 105101.

    In your case, .NET MAUI uses ahead-of-time compilation through Mono's AOT compiler, which compiles managed code to native binaries. Traditional stack canary detection tools (like checksec, MobSF, or other binary analyzers) look for specific symbols and code patterns (such as __stack_chk_fail) that are inserted by gcc/clang with flags like -fstack-protector-strong. The Mono AOT compiler simply doesn't generate these markers, even though your app may have other memory safety protections in place.

    For Android specifically, there was issue at https://github.com/dotnet/android/issues/9786 discussing this exact problem with binary scanners not recognizing protections in .NET MAUI Android builds. Although this was a duplicate of 105101, the dev already explained why this was a false positive.

    If stack canaries are an absolute requirement for compliance in your organization, I would suggest engaging on the GitHub issues (particularly https://github.com/dotnet/runtime/issues/105101) to add priority to this feature request. However, based on the discussions I've seen, implementing traditional stack canaries in Mono AOT is not currently on the immediate roadmap.

    In the meantime, the best path forward is working with your security team to establish that .NET MAUI's memory safety model provides equivalent or better protection than stack canaries alone, and that the scanner results represent a tooling mismatch rather than an actual security vulnerability.

    While these are non-Microsoft site, they are the official Github repositories maintained by Microsoft.

    Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

    1 person found this answer helpful.
    0 comments No comments

  2. kagiyama yutaka 1,170 Reputation points
    2026-02-13T08:02:56.6766667+00:00

    u just check the AOT‑native binary and if __stack_chk_failshows up in the symbol table, that’s the whole verification. and if a scanner says “not enabled”, u just hand over that symbol dump and a few bytes of prologue showing the guard load.

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.