How does "core.img" load modules and interact with filesystems without a kernel?

GRUB has its own kernel, which provides common services and frameworks for the rest of the bootloader. This can run in a variety of contexts, including “bare metal” with direct hardware access, simple BIOS-style services (as used in MBR-based x86 configurations) and less basic environments like EFI (which is closer to a single-tasking operating system, with support for running programs, allocating memory etc.).

core.img’s job isn’t to load the OS and kernel; it’s to allow GRUB to find its configuration file and any other modules it may need. To do this, core.img itself contains more than the GRUB kernel; it also includes the drivers necessary for GRUB to find the rest of itself, so at least those required to access the relevant disks and file systems. See the “GRUB image files” chapter in the user manual for details. This combined image is how GRUB can access the files it needs to load; on an MBR x86 PC with /boot using Ext2 for example, it would include the biosdisk module to access disks using the system BIOS, the part_msdos module to interpret the partition table, and the ext2 module to access the contents of the Ext2 file system. Thus GRUB can find its configuration file, and then load any other module it needs. Ultimately the combination of modules in core.img and /boot enable it to initialise the display, show its menu if necessary, find the appropriate kernel and initramfs, load them into memory and boot the kernel.

Since you’re curious about how GRUB works, you might find the GRUB developers manual interesting, in particular the “Finding your way around” chapter.

“Modules” is a rather generic term; it doesn’t necessarily refer to kernel modules.

I'll post my own answer as I think I understand enough now about how the files can be located without a kernel. In the documentation (https://www.gnu.org/software/grub/manual/grub/grub.html) it states:

"One of the important features in GRUB is flexibility; GRUB understands filesystems and kernel executable formats, so you can load an arbitrary operating system the way you like, without recording the physical position of your kernel on the disk. Thus you can load the kernel just by specifying its file name and the drive and partition where the kernel resides. "

Additionally, I researched the how modules are loaded in RAM with GRUB when using MBR as opposed to UEFI and found that it loads modules located in the directory below:

/boot/grub/i386-pc 

As such one of those modules is named ext2.mod, which subsequently is used to load other versions of ext such as ext3 and ext4, and this directory is still used with x64 MBR based systems.

I then discovered how the disks drivers/modules are loaded, and there is a module in that same directory called: biosdisk.mod . This is a series of software interrupt routines provided by the BIOS (Basic Input/Output System) that handle low-level disk operations. They are used by GRUB to perform disk-related tasks before the operating system's own drivers take over.

As such, this leads me to me answer as to how it's possible to be able to communicate with hardware, and understand a filesystem without a kernel. It's a series of modules within GRUB that can be used to locate files on the disk. This is why GRUB is able to locate the initramfs, and kernel to load a temporary filesystem in RAM.

Took me a really long time to find this info, so I hope this helps someone else. I'm also quite glad that I'm technically capable enough to ignore incorrect answers, even when I get downvoted for being right.