Attempt to use a blank (nulls just test sample) 64-byte stub:

4D5A0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000

Attach it via format pe64 on 'stub.bin':

4D5A4000010000000400000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000000040000000

FASM treats it as a legacy MZ executable (e_lfarlc < 0x40) and overwrites e_cblp, e_cp, e_cparhdr, and e_lfarlc.
How to attach a raw stub as-is without FASM modifying these fields?

Also tested with 0xFF fill:

4D5AFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40000000

• FASM 1: error: value out of range. (or out of memory)
• FASM 2: (heavy lag) Error: error reading file 'stub.bin'.

In FASM 2 (pe.inc), e_cp = 0xFFFF calculates .TEMPLATE_LENGTH ≈ 32MB, and it tries to read 32MB from a 64-byte file. Can this file size check
be added or bypassed?

Some fields in the MZ header need to be correct for the loader to find the PE header. So modifying the header is needed for the file to load correctly. Without the changes the file is not valid.

To get a raw header with all zero bytes, manually overwrite the header after fasm creates the binary. The file probably won't run after that because the PE header offset is lost. Try it and see what Windows makes of it.

The PE offset at 0x3C is already set (40 00 00 00), so it runs fine on Windows.
An attached stub can be bigger than 64 bytes, so manually editing fields afterwards isn't practical. Having FASM attach it as-is would be much better.

As noted here, I am aware that current PE loaders do not care about MZ header fields other than the "MZ" signature and the PE offset. But this is not an universal rule and fasm aims to produce files that should be valid for various legacy systems, too.

Therefore I second revolution's suggestion to manually overwrite the header in post-processing. With fasm2 it is very easy:

Yes, but if a user supplies a non-standard custom DOS stub, FASM silently "fixes" it - altering the output without any warning.
For comparison, Microsoft Linker (v14.51) leaves the stub untouched except for e_lfanew (and adding the Rich Header). Even with an almost-blank stub (only e_magic and e_lfanew), it issues a warning and attaches it as-is.

I'm not going to produce a malformed MZ header just because makers of other software decided that it's not important anymore. Even if not to others, it is important to me (in part due to fasm's DOS roots).

And with fasm2 you can do anything you want anyway, either by post-processing as demonstrated above, or even by making a customized PE.INC.

With fasm 1 post-processing is an option too, but requires separate stages (like the ones made by Grom PE).